Copy Link
Add to Bookmark
Report
OndaQuadra 00
___ ___ ____ ___
/\ \ /\__\ /\ \ /\ \
/00\ \ /NN| | /DD\ \ /AA\ \
/0/\0\ \ /N|N| | /D/\D\ \ /A/\A\ \
/0/ /\0\ \ /N/|N| |__ /D/ /\D\___\ /A/_/\A\ \
/0/ / /0|--|/N/ |N| /\__\ /D/_/ \D| | /AA\ \ \A\__\
/0/_/ /0/ / \/__|N|/N/ / \D\ \ |D| |/A/\A\ \/A/ /
\0\ \/0/ / |N/N/ / \D\ \ |D| |\/_/\A\/A/ /
\0\ /0/ / |NN/ / \D\ \|D| | \AA/ /
\000/ / /N/ / \D\/DD|__| /A/ /
\0/__/ \/__/ \DDD/__/ /A/__/
___ ___ ___ ___ ___
/\ \ ___ /\ \ /\ \ /\ \ /\ \
/QQ\ \ /\__\ /AA\ \ /DD\ \ /RR\ \ /AA\ \
/Q/\Q\ \ /U/ / /A/\A\ \ /D/\D\ \ /R/\R\ \ /A/\A\ \
/Q/ /\Q\ \ /U/ / ___ /A/_/\A\ \ /D/ /\D\ _\ /R/ /\R\ \ /A/_/\A\ \
/Q/ / \Q|--| /U/ / /\__\ /AA\ \ \A\__\ /D/_/ \D| | /R/ / \R\__\ /AA\ \ \A\__\
/Q/_/ /Q/ / /U/_/ /U/ //A/\A\ \/A/ / \D\ \ |D| |/R/ / __|R| //A/\A\ \/A/ /
\Q\ \ /Q/ / \U\ \ /U/ / \/_/\A\/A/ / \D\ \ |D| |\/ / |RRR/__/ \/ /\A\/A/ /
\Q\_/Q/ / \U\_/U/ / \AA/ / \D\ \/D| | \/ |R| | \/ \AA/ /
\QQQ/__/ \UUU/ / /A/ / \D\/DD|__| |R| | /A/ /
\QQ| | \U/__/ /A/__/ \DDD/__/ |R|_| /A/__/
|Q|__|
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ #00 - 18/12/2000 |
+-------------------------------------------------------------------------------+
| Tutto nel ciberspazio |
| E' scandito dalla squarewave |
| Dei micro-processori |
| Il clock dei micro |
| E' come |
| Un battito cardiaco |
| Elettronico... |
+-------------------------------------------------------------------------------+
| http://ondaquadra.cjb.net ~ ondaquadra@hackmaniaci.com |
+-------------------------------------------------------------------------------+
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
+-------------------------------------------------------------------------------+
| INDICE |
+-------------------------------------------------------------------------------+
| [L0GiN] |
| 0x00 EDiT0RiALE..................................................... [JEYoNE] |
| 0x01 GURU MEDiTATi0N ............................................ [Tritemius] |
| 0x02 ME LO HA DETTO Mi0 CUGGGiN0 ................................. [oq~staff] |
| 0x03 RETR: LA P0STA Di 0Q ........................................ [oq~staff] |
+-------------------------------------------------------------------------------+
| [HACKiNG] |
| 0x04 S0CKSCAP32 E L'US0 DEi S0CKS ............................... [Malkavian] |
| 0x05 TECNiCHE Di SCANNiNG ....................................... [Tritemius] |
+-------------------------------------------------------------------------------+
| [NETW0RKiNG] |
| 0x06 BUTT SNiFF & iNTR0 AL TCP/iP (1/2).......................... [Tritemius] |
+-------------------------------------------------------------------------------+
| [CRACKiNG] |
| 0x07 PEDiT 1.6 .............................................. [Andrea Geddon] |
+-------------------------------------------------------------------------------+
| [MiSC] |
| 0x08 iNTR0DUZi0NE Ai MUD ............................................ [Mysha] |
| 0x09 ZMUD E LE SUE P0TENZiALiTA'..................................... [Mysha] |
| 0x0A CR0NACHE DALL0 SMAU ......................................... [Tdi110cv] |
+-------------------------------------------------------------------------------+
| [L'APPRENDiSTA STREG0NE] |
| 0x0B C0DiNG4DUMMiES: EXCEL: APPARENTEMENTE UN'APPLiCAZi0NE........... [Mysha] |
| 0x0C C0DiNG4DUMMiES: VB E RiS0LUZi0NE DEGLi H0ST ................... [JEYoNE] |
| 0x0D CRACKiNG4DUMMiES: CRACKiNG 4 T0TALLY NEWBiES ................ [_phobos_] |
+-------------------------------------------------------------------------------+
| [SHUTD0WN] |
| 0x0E ETiCA ....................................................... [Tdi110CV] |
+-------------------------------------------------------------------------------+
| [ALLEGATi] |
| 0x00 Guida per lo sviluppo di circuiti stampati ....................... [HTB] |
| 0x01 Host from IP (vedi articolo 0x0C) ............................. [JEYoNE] |
| 0x02 Bromografo ................................................... [Tin_Man] |
+-------------------------------------------------------------------------------+
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [L0GiN] #00 - 18/12/2000 |
| EDiT0RiALE [JEYoNE] 0x00/0x0E |
+-------------------------------------------------------------------------------+
--EDITORIALE--
Comincia così la storia, spero lunga, di questa nuova e-zine.
Che cos'è OndaQuadra, è una domanda che non ci è ancora pervenuta, soltanto perchè
non è ancora uscito nessun numero della rivista, ma che sicuramente arriverebbe,
se non mi mettessi a spiegarlo qui.
OndaQuadra è nata da una chiacchierata in chat, in una serata come tante altre, si
stava parlando appunto di mettere in piedi una rivista eletronica, più semplice di
quelle che ci già sono in giro, ma con uno scopo finale, FAR CAPIRE A CHI LEGGE
COME UTILIZZARE TALE PROGRAMMA E COME FARE QUESTA O QUELLA COSA.
Sicuramente il cammino di questa rivista e lo scopo cambierà con il tempo, non ci
saranno sotanto recensioni di programmi, ma ci saranno altri articoli, che non
spiegheranno l'utilizzo di un programma o di un altro, ma faranno tutt'altro, comunque
diciamo che il punto di partenza della rivista è stato questo.
A questo proposito volevo chiedere a tutti i lettori di inviarci una mail, di scrivere
i pareri, le lamentele, i complimenti ( : ]!!) e quant'altro venga in mente, giusto
per farci capire se quello che stiamo facendo merita e se è il caso di proseguire.
Oltre a questo potrete fare domande, a partire dal prossimo numero ci sarà un "angolo
della posta" in cui cercheremo di rispondere alle vostre domande, esporremo i problemi
di chi ci legge, a cui magari qualcun'altro sa dare risposta.
Si tratteranno svariati argomenti, come si può vedere dal sommario più in basso, gli
articoli sono divisi per argomento, tra un articolo e l'altro ci sarà un cosiddetto
separatore, in modo tale che, se un articolo non interessa, si capisce subito dove
finisce e dove comincia l'altro.
A questo proposito volevo ringraziare tutte le persone che hanno collaborato all'uscita
di questo primo numero, invitandoli a continuare così, e volevo anche invitare
tutti i lettori della rivista ( ce ne saranno? hehehe! :)) che si sentono in grado
di insegnare qualcosa, a non esitare e ad inviarci il loro articolo, che, se sarà
reputato idoneo, sarà pubblicato sul prossimo numero.
Con questo vi saluto, augurando una buona lettura a tutti.
°--JEYoNE--.
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [L0GiN] #00 - 18/12/2000 |
| GURU MEDiTATi0N [Tritemius] 0x01/0x0E |
+-------------------------------------------------------------------------------+
0NDAQUADRA
==========
Ondaquadra e' un luogo mentale che prende forma sui vostri monitor e si
proietta giu' nella vostra coscienza; e' un locale immaginario dove si
incontrano smanettoni, visionari, saiberscrittori, pirati-informatici, hacker
e l4m3rz; anarcoidi, libertari, hacktivist: tutti i freak (o phreaker ?)
della nuova Era.
Non una nuova rivista sulla "sicurezza informatica", ma un "suk", un mercato,
una nuova agora'.
Vi aspettiamo: amighisti, amanti del Mac, scrittori di videogiochi per GameBoy.
Aspettiamo chi si diletta con i "crobots", chi gioca con gli emulatori, chi
si ostina a scrivere programmi per Commodore 64 (!), chi usa in modo non
banale ma creativo la tecnologia.
Internet e' piena di gente che conosce il prezzo di tutto e il valore di nulla.
Non e' solo e-commerce, ma anche e soprattutto e-mozioni; se la Rete
e' il sistema nervoso della Modernita' noi saremo la sua Anima: lasciate
urlare il nostro cuore di silicio !!!
BATRAC0Mi0MACHiE (accento sull'ultima "i")
==========================================
Quante ne ho viste. La prima fu vent'anni fa: Atari VCS2600 contro Intellivision.
Fini' male per tutti e due; arrivo' Colecovision e mando' a casa tutti. Si parla
di console per videogiochi naturalmente. L'angolo della posta delle riviste
specializzate era quasi tutto dedicato alle battaglie tra guelfi e ghibellini
videoludici. Batracomiomachia: "contesa vana e ridicola per futili motivi",
dice il Devoto-Oli; parola di derivazione greca: "la battaglia tra rane e topi".
Poi arrivarono gli "home-computer". Il Commodore Vic20, il Sinclair zx80; ma
la vera guerra fu tra Commodore 64 e Spectrum 48. Arrivarono i 16-bit e
spazzarono via tutto.
La nuova religione si chiamava Amiga, ma naturalmente c'era un rivale: l'Atari ST.
Il nome del vincitore lo conoscete tutti: Microsoft. Arrivo' Linux, e si
apri' la stagione delle batracomiomachie tra sistemi operativi. "Winzozz ha
lo schermo blu","Se vuoi essere un h4ck3r devi usare Linux".
Per non parlare della ridicolissima disputa hacker/non-hacker, l4m3r/l33t...
In verita' vi dico: uno spettro si aggira per la Rete: l'unita' degli smanettoni.
Scopo della liberta' di comunicazione e' la pace, non la guerra.
E tu cosa vuoi essere ? Rana o topo ?
MATRiX, PLAT0NE E iL MiT0 DELLA CAVERNA
=======================================
"[...] Pensa a uomini, in una caverna sotterranea, dotata di un'apertura
verso la luce che occupi tutta la parete lunga. Essi vi stanno chiusi fin
dall'infanzia, carichi di catene al collo e alle gambe che li constringono
a rimanere li e a guardare soltanto in avanti poiche' la catena al collo
impedisce loro di volgere in torno il capo. In alto, sopra di loro, brilla
lontana una fiamma; tra questa e i prigionieri corre una strada in salita,
lungo la quale e' stato costruito un muretto, simile ai paraventi divisori
al di sopra dei quali i saltimbanchi mostrano al pubblico i loro prodigi. [...]
(Platone, "La Repubblica", Libro VII).
Cosi' si apre il settimo libro di una delle piu' importanti opere di Platone.
In sintesi il filosofo greco parla di una societa' in cui i cittadini
(definiti "prigionieri") vengono costretti dalla nascita a credere che le ombre
che vedono siano la "realta'", ignorando di fatto l'esistenza della "luce"
(la verita'), visione la quale terrorizzerebbe gli individui non pronti
a tale "rivelazione". Ma il Filosofo, una volta liberatosi dalle catene che
lo imprigionano all'"illusione" (che i buddhisti chiamano "Maya"), agisce
per "risvegliare" gli altri "prigionieri".
Matrix, una volta svestito dagli effetti speciali e dall'ambientazione (o
travestimento ?) fantascientifica e futuribile, ci veicola gli stessi concetti.
Neo, "l'eletto" (l33t!!!), una volta risvegliato (seguendo il "Bianconiglio di Alice"),
si ritrova nel "paese delle meraviglie", trovandosi di fronte ad una realta' sconvolgente.
"Io ti mostro la via: sta a te varcare la soglia..."
(Morpheus,"Matrix")
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [L0GiN] #00 - 18/12/2000 |
| ME LO HA DETTO Mi0 CUGGGiN0 [oq~staff] 0x02/0x0E |
+-------------------------------------------------------------------------------+
"Mio cugggino mi ha detto che da bambino e' morto"
(Elio e le Storie Tese)
Tutti le conosciamo: le leggende metropolitane. Storie raccontate dall'amico,
dall'amico dell'amico, talvolta riprese e amplificate dai giornali. Anche
quaggiu' nel saiberspeis circolano. Chi non ricorda la palla megagalattica che
diceva che era possibile ricaricare le schede telefoniche lasciandole 24 ore
davanti a un vecchio televisore in b/n ? La variante era quella di mettere la
scheda sopra un Commodore C64... Tu ci provavi, ma non succedeva niente...
Qui interviene mio cugggino:"Ma ci hai messo la lacca ?". Gia', la lacca: sulla
parte magnetizzata bisogna spruzzare la lacca prima di esporre la scheda alle
miracolose onde elettromagnetiche emanate dal C64: e via a riprovare dopo aver
irrorato abbondantemente la povera scheda...
Ma veniamo ai nostri giorni. Ne ha parlato anche "Punto Informatico" (http://
www.punto-informatico.it); ha allarmato la polizia australiana: alcuni cellulari
prodotti dalla Nokia permettono (permetterebbero) di intercettare gli Autovelox
della Polizia ! Chi ha un Nokia provi:
Opzioni Sicurezza
Grup.Limit.Utenti
Mettere "00000"
A questo punto, quando si giunge in prossimita' dell'Autovelox, il cello dovrebbe
suonare... Altre versioni dicono che il numero da inserire indica il raggio
d'azione espresso in metri...
Sulla mailing-list di spaghetti-phreaker se n'e' parlato molto (pure troppo).
Lapidaria la risposta di Blum a chi gli chiedeva se fosse vera la storia qui
citata:"no".
Voi provate, ma se si rivela una vaccata, non prendetevela con me: me lo ha
detto mio cugggino.
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [L0GiN] #00 - 18/12/2000 |
| RETR: LA P0STA DI OQ [oq~staff] 0x03/0x0E |
+-------------------------------------------------------------------------------+
Questa sezione, che prende il nome dal comando pop3 che si usa per
recuperare i messaggi dal server, sara' curata da Malkavian ed e' rivolta ai
lettori: critiche, consigli, suggerimenti, proposte di collaborazione,
andranno inviate a:
ondaquadra@hackmaniaci.com
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [HACKiNG] #00 - 18/12/2000 |
| Sockscap32 e l'uso dei Socks [Malkavian] 0x04/0x0E |
+-------------------------------------------------------------------------------+
"Sockscap32 e l'uso dei Socks"
Eccoci qua a parlare di un programmino per Windows che può rendersi
utile per numerosi scopi.
Il programma in questione è Sockscap32. Potete scaricarlo da siti
che trattano di hacking e argomenti affini. Il programma si occupa di
far passare tramite un socks le connessioni effettuate dai vostri
client per i servizi più disparati.
Innanzitutto chiariamo cos'è un socks: in breve è il servizio che
consente, ai computer appartenenti a una rete protetta da firewall,
di comunicare con l'esterno passando per il firewall. Spieghiamoci
meglio. Un ipotetico pc appartiene ad una ipotetica rete LAN (Local
Area Network) ed essa è connessa a internet tramite un computer che
funge da firewall (il firewall blocca o filtra i pacchetti
provenienti da internet e diretti ai pc appartenenti alla LAN,
permette invece ai pacchetti generati dai pc della LAN di "uscire"
verso internet. Quindi protegge i computers all'interno della rete
locale da connessioni non autorizzate dall'esterno). Il pc della rete
locale invia i suoi pacchetti verso internet attraverso il firewall,
tramite il servizio socks. Il servizio socks lavora sulla porta 1080.
Armandoci della santa pazienza e di uno scanner (o più velocemente
cercando sui siti che contengono liste di proxy, socks e wingate) ci
capiterà di trovare un socks che si lascia attraversare, non solo da
pacchetti generati da pc interni alla rete locale di cui esso fa
parte, ma anche da pacchetti generati da utenti esterni alla suddetta
rete. Cioè da pacchetti generati da NOI. Quindi in parole povere il
socks farà da intermediario fra noi e il server al quale ci
colleghiamo. Sockscap32, come detto, "obbliga" i pacchetti generati
da un nostro client (per esempio telnet.exe, il quale per default non
supporta l'uso di socks) a passare tramite socks. Passiamo a un
esempio pratico per capire meglio.
Io voglio inviare una e-mail anonima (esempio "classico")
collegandomi direttamente a un server smtp usando il telnet di
windows. Come scritto in moltissimi manuali di hacking (non specifico
qui tutto il procedimento...) io andrò a dialogare direttamente con
il server smtp scrivendo i vari comandi, come farebbe (in maniera a
noi invisibile) il nostro client di posta elettronica. Posso quindi
tentare di falsificare non solo l'intestatario della mail, ma anche
l'header "Received" della mail stessa, per far sembrare che sia stata
scritta da un'altra persona. Però, se fate una prova, vi accorgerete
che questo non basta a garantirvi l'anonimità, perchè comunque nelle
intestazioni della e-mail rimarrà impresso sempre e comunque il
vostro IP, che viene oramai rilevato da tutti i server di posta
elettronica al momento della connessione. Per cui dobbiamo trovare un
altro metodo: qui ci viene in aiuto Sockscap32!
Apriamo il Sockscap, clicchiamo sul menù "file" e quindi su "setup".
Comparirà la schermata dove inserire i dati del socks (possibilmente
funzionante:)) che avrete precedentemente trovato. Nel campo "SOCKS
Server" inserite l'hostname del socks, in "port" inserite sempre
1080, in SOCKS User ID" lasciate "nobody", selezionate infine
"Socks4". Ora cliccate su OK e passiamo ad inserire il nome del
client del quale volete "dirottare" i pacchetti tramite socks.
Cliccate su "New", poi su "browse" ed usate il filemanager per
trovare la locazione sull'hard disk del programma client che volete
usare. In questo caso sarà: c:\windows\telnet.exe
Cliccate su ok e vedrete che il nome del client (Telnet in questo
esempio) comparirà nel campo delle applicazioni. Cliccate ora su "Run
Socketsfield" e vedrete aprirsi il telnet. Ora usatelo come avreste
fatto normalmente e provate a spedire a voi stessi una mail di prova
(ripeto che non elencherò qui le fasi di spedizione tramite server
smtp di una mail, perchè sono ampiamente trattate su quasi tutti i
manuali per hacking). Quando la mail vi arriverà andate a vedere le
intestazioni (Headers) dell'e-mail e noterete che nel campo
"Received", al posto del vostro IP, ci sarà l'IP del socks da voi
usato. Bello, no? La cosa carina di Sockscap32 è che lo si può usare
per molte altre applicazioni: per fare un esempio potreste provare a
telnettarvi tramite socks ad una shell o ad un wingate e poi fare un
rimbalzo (bounce) da questi ad altri wingate o shell, per poi
sferrare un attacco, ecc... Oppure un esempio più "terra-terra" può
essere utilizzare Sockscap col client di un trojan che abbiamo
installato su qualche pc (BO, Netbus o altri...). In questo modo,
collegandoci col server del trojan, lasceremo (nel caso il possessore
del pc trojanizzato abbia attivato un firewall) l'IP del socks e non
il nostro nei suoi Log. Infine potrete usare Sockscap per effettuare
uno scanning da windows tramite socks. Sì, avete capito bene: anche
se da windows non si può attuare uno stealth scanning (come si può
fare su linux con nmap) è comunque possibile con questa tecnica
effettuarne uno abbastanza sicuro. Infatti lascerete, anche in questo
caso, l'IP del socks anzichè il vostro nei logs che registrano il
vostro tentativo di scansione. Quindi un margine di anonimità
l'avrete guadagnato. Per fare ciò inserite il vostro scanner
preferito (io ho usato più volte Superscan) nel campo delle
applicazioni di Sockscap e lanciatelo. Poi non vi resta che dare in
pasto allo scanner la lista degli IP da scannerizzare. L'unica
accortezza è usare un socks abbastanza veloce e abbassare la velocità
dello scanner, così da non farvi cadere la connessione con il socks
stesso.
Insomma c'è da divertirsi.
Considerate anche il vantaggio che di Socks funzionanti ce ne sono
moltissimi, quindi sono abbastanza facili da trovare (anche se va
ricordato che i Socks loggano, cioè tengono traccia dei pacchetti che
vi passano attraverso, quindi...fate un po' di attenzione).
Concludo l'articolo augurandovi buon divertimento e offrendomi per
ogni chiarimento: scrivete pure a: malkavian@malkavian13.org
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [HACKiNG] #00 - 18/12/2000 |
| TECNiCHE Di SCANNiNG [Tritemius] 0x05/0x0E |
+-------------------------------------------------------------------------------+
iNTR0
=====
In questo articolo intendo descrivere e illustrare una sessione di scanning in
pratica, analizzata a basso livello dal punto di vista del tcp. Nella seconda
parte si parlera' invece di come ottenere i "banner" dai sistemi, per poter
cosi' controllare la versione e il "grado" di vulnerabilita'.
STRUMENTi
=========
Per realizzare questo articolo ho usato due strumenti comunissimi e facilmente
reperibili:
nmap, ovvero il piu' celebre e potente scanner in circolazione;
buttsniff, ottimo sniffer per Windows 95/98.
CONNECT
=======
La prima tecnica che analizzo e' la classica "connect", la piu' banale delle
tecniche di scanning. Questa operazione puo' essere effettuata manualmente
utilizzando telnet o netcat, sia da Windows, sia da Linux o da qualsiasi altra
piattaforma fornita di stack tcp. Questo metodo e' utilizzato da tutti gli
scanner per Windows piu' o meno lamereschi.
Questa tecnica non fa altro che tentare di stabilire una connessione con una
porta tcp: molto banalmente, se l'operazione riesce significa che la porta e'
aperta !
Con nmap basta digiare questo comando per ottenre uno scanning-connect
nmap -p 1080 192.168.0.2
dove -p serve per specificare la porta (o il range di porte) che vogliamo
testare (in questo casto 1080); 192.168.0.2 e' l'ip dell'host da sondare.
A questo punto non si puo' non parlare del "three-way-handshake".
Una connessione tcp viene avviata al termine di una negoziazione denominata
"three-way-handshake"; Questo handshake consiste in un'operazione in tre fasi:
nella prima, il client invia un pacchetto tcp con il solo flag SYN attivo; nella
seconda fase il server risponde. La risposta puo' essere di due tipi: porta aprta
op porta chiusa. Se la porta e' chiusa il server risponde con un pacchetto
con i flag ACK RST; altrimenti il server invia un pacchetto tcp con i flag
SYN e ACK. La terza parte vede ancora protagonista il client, che invia a sua
volta un pacchetto ACK al server e la negoziazione e' terminata: puo'
iniziare la trasmissione di dati.
Questo in modo molto semplificato; non ho volutamente considerato i valori di
ISN (initial sequence number) e ack, perche' la loro spiegazione va al la' degli
obiettivi del presente articolo.
Ricapitolando, vediamo un semplice schema di three-way-handshake
il client invia SYN al server
client SYN --> server
il server risponde con SYN ACK
server SYN ACK --> client
il client invia ACK al server
client ACK --> server
l'handshake e' terminato, inizia lo scambio di dati
client PUSH ACK --> server
Ora avviamo il nostro sniffer in modalita' "disk-dump" e analizziamo il
risultato del comando che abbiamo visto in precedenza
nmap -p 1080 192.168.0.2
vediamo il log:
Source IP: 192.168.0.1 Target IP: 192.168.0.2
ICMP Length: 0 ChkSum: 59A2 Code: Echo Message
Source IP: 192.168.0.2 Target IP: 192.168.0.1
ICMP Length: 0 ChkSum: 61A2 Code: Echo Reply
Come vediamo, la macchina dalla quale eseguo lo scanning ha come ip 192.168.0.1
Ma, cosa significa questo log ?
Nmap, prima di tentare la connessione, testa la "presenza" della macchina.
Ovvero, "pinga" la macchina target per cercare di capire se l'host e'
raggiungibile o meno inviando un paccheto ICMP di tipo "echo"; 192.168.0.2 risponde
con un pacchetto ICMP "echo reply"; a questo punto nmap procede con il
three-way-handshake:
(e' possibile evitare che nmap effettui il "ping" utilizzando l'opzione -P0)
Il client invia SYN; questo lo vediamo nel campo "Flags": la "S" sta appunto
per SYN; i campi Source IP,Target IP, Source Port, Target Port, non necessitano
di spiegazione; ChkSum e' un campo di controllo sull'integrita' dei dati.
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 1032 Target Port: 1080 Seq: 1E8734B7 Ack: 00000000
Flags: S Window: 32120 TCP ChkSum: 11901 UrgPtr: 0
il server risponde con SYN ACK: la porta e' aperta.
Source IP: 192.168.0.2 Target IP: 192.168.0.1
TCP Length: 0 Source Port: 1080 Target Port: 1032 Seq: 00116211 Ack: 1E8734B8
Flags: SA Window: 8760 TCP ChkSum: 54467 UrgPtr: 0
il client invia ACK: il three-way-handshake e' concluso con successo, inizia
la trasmissione di dati.
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 1032 Target Port: 1080 Seq: 1E8734B8 Ack: 00116212
Flags: A Window: 32120 TCP ChkSum: 64270 UrgPtr: 0
quindi il client (nmap) chiude la connessione:
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 1032 Target Port: 1080 Seq: 1E8734B8 Ack: 00116212
Flags: FA Window: 32120 TCP ChkSum: 64269 UrgPtr: 0
Source IP: 192.168.0.2 Target IP: 192.168.0.1
TCP Length: 0 Source Port: 1080 Target Port: 1032 Seq: 00116212 Ack: 1E8734B9
Flags: A Window: 8760 TCP ChkSum: 11509 UrgPtr: 0
Source IP: 192.168.0.2 Target IP: 192.168.0.1
TCP Length: 0 Source Port: 1080 Target Port: 1032 Seq: 00116212 Ack: 1E8734B9
Flags: FA Window: 8760 TCP ChkSum: 11508 UrgPtr: 0
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 1032 Target Port: 1080 Seq: 1E8734B9 Ack: 00116213
Flags: A Window: 32120 TCP ChkSum: 53681 UrgPtr: 0
La "F" nel campo flags sta per "FIN"; questo flag viene utilizzato per chiudere
le connessioni.
SYN-SCAN (Half-open)
====================
Il metodo che abbiamo appena visto ha un problema fondamentale: e' facilmente
rilevabile. Basta un programma stupidissimo scritto in Visual Basic per
intercettare un tentativo di connessione e rilevare l'ip dell'host remoto.
Una modo intelligente per evitare che questo accada (almeno in parte) e'
quello di "interrompere" il "three-way-handshake" a meta' (half-open).
Cosi' facendo l'host remoto non si accorgera' del nostro tentativo di
collegamento o comunque syslogd non registrera' il nostro ip (certo, se di
la' c'e' iplog attivo...).
Allora, per effettuare uno scanning di questo tipo bisogna utilizzare l'opzione
-sS:
nmap -p 1080 192.168.0.2 -sS (SYN, half-open)
se mettete -P0 eviatate di pingare l'host target.
Source IP: 192.168.0.1 Target IP: 192.168.0.2
ICMP Length: 0 ChkSum: 62C2 Code: Echo Message
Source IP: 192.168.0.2 Target IP: 192.168.0.1
ICMP Length: 0 ChkSum: 6AC2 Code: Echo Reply
solito three-way-handshake
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 44967 Target Port: 1080 Seq: 67BD8B8F Ack: 00000000
Flags: S Window: 1024 TCP ChkSum: 33634 UrgPtr: 0
il server risponde...
Source IP: 192.168.0.2 Target IP: 192.168.0.1
TCP Length: 0 Source Port: 1080 Target Port: 44967 Seq: 00142F58 Ack: 67BD8B90
Flags: SA Window: 8576 TCP ChkSum: 7849 UrgPtr: 0
... e il client gli sbatte la porta in faccia !
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 44967 Target Port: 1080 Seq: 67BD8B90 Ack: 00000000
Flags: R Window: 0 TCP ChkSum: 34655 UrgPtr: 0
La chiave e' qui sopra: nei flags notate la "R". Questo significa che nmap
resetta la connessione, piantando a meta' l'handshake.
NASC0NDERSi NELLA F0LLA
=======================
Anche il SYN scan che abbiamo appena visto puo' essere rilevato, e il nostro
ip reale puo' essere cosi' svelato. Non c'e' molto di piu' da fare per nascondere
l'ip sorgente reale, ma si puo' ricorrere a uno stratagemma: effettuare lo
scanning da piu' indirizzi ip contemporaneamente, cosi' da gettare fumo negli
occhi al "guardiano" di turno, utilizzando pacchetti "decoy" (pacchetti-esca).
Nmap permette di specificare uno o piu' indirizzi "falsi" come ip sorgente:
oltre a quello reale (necessario per ottenere i risultati dello scanning!),
verranno inviati pacchetti "devoy" con l'ip sorgente opportunamente ritoccato.
Il seguente comando lanscia uno scanning half-open contro 192.168.0.2, sonda
la porta 1080; inoltre invia altri pacchetti SYN dall'indirizzo 1.2.3.4:
nmap -p 1080 192.168.0.2 -sS -D1.2.3.4
qui c'e' il solito ping...
Source IP: 192.168.0.1 Target IP: 192.168.0.2
ICMP Length: 0 ChkSum: BE68 Code: Echo Message
ecco il ping proveniente dall'ip falso !
Source IP: 1.2.3.4 Target IP: 192.168.0.2
ICMP Length: 0 ChkSum: BE68 Code: Echo Message
Source IP: 192.168.0.2 Target IP: 192.168.0.1
ICMP Length: 0 ChkSum: C668 Code: Echo Reply
La sequenza e' uguale al SYN scan (E' un SYN scan !), in piu' c'e' il
pacchetto decoy:
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 33754 Target Port: 1080 Seq: 95EDA54C Ack: 00000000
Flags: S Window: 4096 TCP ChkSum: 23362 UrgPtr: 0
Source IP: 1.2.3.4 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 33754 Target Port: 1080 Seq: 95EDA54C Ack: 00000000
Flags: S Window: 4096 TCP ChkSum: 6118 UrgPtr: 0
Source IP: 192.168.0.2 Target IP: 192.168.0.1
TCP Length: 0 Source Port: 1080 Target Port: 33754 Seq: 0018D246 Ack: 95EDA54D
Flags: SA Window: 8576 TCP ChkSum: 24470 UrgPtr: 0
Source IP: 192.168.0.1 Target IP: 192.168.0.2
TCP Length: 0 Source Port: 33754 Target Port: 1080 Seq: 95EDA54D Ack: 00000000
Flags: R Window: 0 TCP ChkSum: 27455 UrgPtr: 0
A CACCiA Di DEM0Ni
==================
"La coerenza e' la virtu' degli imbecilli"
(Oscar Wilde)
Tutte queste tecniche sono belle, efficaci e tutto quanto, ma c'e' un pronlema:
alla fine, per poter "forzare" un sistema, dobbiamo per forza conoscere il
tipo di demone e la versione per poter agire in qualche modo. Per far cio'
non c'e' che un modo: connect() e read del banner ! Ci si collega alla macchina,
(sulla porta 21 per esempio), e si leggono i primi 500 caratteri; quindi si
logga il tutto per uso futuro.
Per questo scopo sono necessari alcuni strumenti: innanzitutto una shell "sicura"
di cui si ha il controllo; un programma o uno script per produrre liste di
ip o di hostname; infine uno scanner di "banner".
La shell la dovete trovare voi. Io fornisco un semplicissimo programma per
creare liste di ip (indirizzi di classe C) e un programma per estrarre gli
ip dai file prodotti con 'host -l dominio > dominiolog.'
Inoltre allego "lscan" di Mixter, utile per cercare e "versionare" alcuni
demoni notoriamente "bacati".
8<--------------------------------------------------------------------------------------------
/* IP list maker
Crea una lista di ip utilizzando come input
il risultato del comando host -l
Tritemius
1.00 13/02/00
0.99 23/01/00
gcc iplim.c -o iplim
*/
#include <stdlib.h>
#include <stdio.h>
#include <strings.h>
#include <ctype.h>
void usage(char *cmd) {
printf("\nIP list maker 1.00 ~ Tritemius 13/02/00\n");
printf("usage: %s <hostlist> <outfile>\n",cmd);
}
void main(int argc,char *argv[]) {
FILE *hostlist;
FILE *iplist;
char *sp;
char linein[1024];
int i;
if (argc<3) {
usage(argv[0]);
exit(1);
}
if ((hostlist=fopen(argv[1],"rb")) != NULL) {
if ((iplist=fopen(argv[2],"wb")) !=NULL) {
while(!feof(hostlist)) {
sp=fgets(linein,1024,hostlist);
if (sp != NULL) {
for (i=0;i<3;i++) {
sp=strstr(sp," ");
sp+=1;
}
if (isdigit(*sp)) {
if ((strstr(sp,"127.0.0.1")) == NULL)
fputs(sp,iplist);
}
}
}
} else {
printf("Output file error.\n");
exit(1);
}
fclose(iplist);
} else {
printf("Input file error.\n");
exit(1);
}
fclose(hostlist);
}
8<--------------------------------------------------------------------------------------------
/*
* iplim2
* Tritemius 2000
* Linux: gcc iplim2.c -o iplim2
* Win32: lcc iplim2.c
* lcclnk iplim2.obj
*/
#include <stdio.h>
#include <stdlib.h>
#include <strings.h>
void usage(char *cmd) {
printf("Usage: %s <net> <file>\n",cmd);
}
void main(int argc,char **argv) {
FILE *out;
char rete[13];
char *file;
char buffer[20];
int i;
if (argc <=2 ) {
usage(argv[0]);
exit(1);
}
file=argv[2];
out=fopen(file,"w");
if (out == NULL) {
printf("Errore apertura file");
}
strncpy(rete,argv[1],13);
for (i=1;i<255;i++) {
fprintf(out,"%s.%i\n",rete,i);
}
fclose(out);
}
8<--------------------------------------------------------------------------------------------
/* lscan2.c - 1999 (c) Mixter */
/* compile: gcc -O3 -s -Wall lscan2.c -o lscan */
#define INITIAL_TIMEOUT 5 // how long to wait for a connection
#define WAIT_FORK 550000 // wait 1/2 second between forks
#define BIND "ns.log"
#define POP "pop.log"
#define IMAP "imap.log"
#define RPC "mountd.log"
#define FTP "ftp.log"
#define STATUSLOG "status.log"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <netdb.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <signal.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#define SSA sizeof(struct sockaddr)
#define SOX socket(AF_INET,SOCK_STREAM,0)
int s1,s2,s3,s4,s5;
int ncon(int tsock, char *ip, int port, int timeout);
void invoke(struct hostent *host, int port); // udp send
void usage(char *name, char *text); // print usage & die
int validip(char *ip); // check and correct ip address
void fchk(FILE *fp); // check a file
void timedout(int sig); // dummy function
int background(); // background a process
void scan0r(char *ip); // log services for one ip
char buf[75]; // read the first 75 chars from a server
int main(int argc,char **argv)
{
FILE *data,*err;
char ip[30];
int pid;
if((argc!=2)) usage(argv[0],"<ipfile>");
fprintf(stderr,"[0;34mlamerz scan 1.0 by [5mMixter[0m\n");
fprintf(stderr,"[0;34mscanning from %s (pid: %d)[0m\n"
,argv[1] ,(pid=background()));
signal(SIGHUP,SIG_IGN);
signal(SIGCHLD,SIG_IGN); // zombies suck
fchk(data=fopen(argv[1],"r"));
fchk(err=fopen(STATUSLOG,"a"));
fprintf(err,"Started new session. File: %s, PID: %d\n",argv[1],pid);
while(!feof(data))
{
fscanf(data,"%s\n",ip);
if(validip(ip)==1)
{
usleep(WAIT_FORK); // wait between fork()'s (1/2 second default)
if ((pid=vfork()) < 0) { perror("fork"); exit(1); }
if (pid==0) // child
{
scan0r(ip); // collect data for this host & save into files
raise(9);
return 0;
}
}
else fprintf(err,"Invalid IP: %s\n",ip);
}
sleep(60); // wait for the last childs
fprintf(err,"Finished session. File: %s\n",argv[1]);
return 0;
}
void scan0r(char *ip)
{
int tout=INITIAL_TIMEOUT,
s1=SOX,s2=SOX,s3=SOX,s4=SOX,s5=SOX,
bind,pop,imap,rpc,ftp;
FILE *f1,*f2,*f3,*f4,*f5;
fchk(f1=fopen(BIND,"a"));
fchk(f2=fopen(POP,"a"));
fchk(f3=fopen(IMAP,"a"));
fchk(f4=fopen(RPC,"a"));
fchk(f5=fopen(FTP,"a"));
rpc=ncon(s4,ip,635,tout); // we check port 635 because 2.2b29
// mountd always binds on that one
if(rpc==-9) return; // host timed out
else if(rpc>=0) fprintf(f4,"%s\n",ip); // log mountd connect
pop=ncon(s2,ip,110,tout);
if(pop==-9) return; // host timed out
else if(pop>=0)
{
bzero(buf,sizeof(buf));
read(s2,buf,sizeof(buf)); // get popper version
fprintf(f2,"%s %s\n",ip,buf); // log popper connect
}
pop=ncon(s2,ip,109,tout);
if(pop==-9) return; // host timed out
else if(pop>=0)
{
bzero(buf,sizeof(buf));
read(s2,buf,sizeof(buf)); // get popper version
fprintf(f2,"%s !POP2! %s\n",ip,buf); // log popper connect
}
imap=ncon(s3,ip,143,tout);
if(imap==-9) return; // host timed out
else if(imap>=0)
{
bzero(buf,sizeof(buf));
read(s3,buf,sizeof(buf)); // get imap version
fprintf(f3,"%s %s\n",ip,buf); // log imap connect
}
bind=ncon(s1,ip,53,tout);
tout -= 2; // wait 2 seconds less
if(bind==-9) return; // host timed out
else if(bind>=0) // log dns connect
fprintf(f1,"%s\n",ip);
ftp=ncon(s5,ip,21,tout);
if(ftp==-9) return; // host timed out
else if(ftp>=0)
{
bzero(buf,sizeof(buf));
read(s5,buf,sizeof(buf)); // get ftp version
fprintf(f5,"%s %s\n",ip,buf); // log ftp connect
}
fclose(f1); fclose(f2); fclose(f3); fclose(f4); fclose(f5);
raise(9);
return;
}
int ncon(int tsock, char *ip, int port, int timeout) {
int probe;
struct sockaddr_in target;
target.sin_family = AF_INET;
target.sin_port = htons(port);
target.sin_addr.s_addr = inet_addr(ip);
bzero(&target.sin_zero,8);
alarm(0); signal(SIGALRM,timedout); alarm(timeout);
probe = connect(tsock, (struct sockaddr *)&target, SSA);
alarm(0);
if(probe < 0) {
close(tsock);
if(errno == EINTR) return -9;
if(errno == ETIMEDOUT) return -9;
}
return probe;
}
void usage(char *name,char *text)
{
printf("usage: %s %s\n",name,text);
exit(EXIT_FAILURE);
}
int validip(char *ip)
{
int a,b,c,d,*x;
sscanf(ip,"%d.%d.%d.%d",&a,&b,&c,&d);
x=&a;
if(*x < 0) return 0; if(*x > 255) return 0;
x=&b;
if(*x < 0) return 0; if(*x > 255) return 0;
x=&c;
if(*x < 0) return 0; if(*x > 255) return 0;
x=&d;
if(*x < 0) return 0; if(*x > 255) return 0;
sprintf(ip,"%d.%d.%d.%d",a,b,c,d); // truncate possible garbage data
return 1;
}
void fchk(FILE *fp)
{
if(fp==NULL)
{
fprintf(stderr,"Error opening file or socket.\n");
exit(EXIT_FAILURE);
}
return;
}
void timedout(int sig)
{
alarm(0);
raise(9);
}
int background()
{
int pid;
signal(SIGCHLD,SIG_IGN);
pid = fork();
if(pid<0) return -1; // fork failed
if(pid>0)
{
sleep(1);
exit(EXIT_SUCCESS); // parent, exit
}
if(pid==0)
{
signal(SIGCHLD,SIG_DFL);
return getpid(); // child, go on
}
return -2; // shouldnt happen
}
C0NCLUSi0Ni
===========
Qui si e' parlato di tecniche di scanning (half-open in particolare). Nella
prima parte abbiamo visto come funziona in pratica uno scanning, analizzando
i pacchetti in transito sulla rete; la seconda parte, piu' prosaica, ha visto
come protagonista il vecchio metodo di probing basato sulla connessione completa
e sul recupero di informazoni dal sistema.
Esistono altri tipi di scanning, come il FIN, che prevede l'invio di pacchetti
FIN tcp; il 'null', tipo di scanning basato su pacchetti tcp "vuoti" (senza
nessun flag settato); il Xmas tree (l'albero di Natale), dove vengono inviati
pacchetti tcp con i flag URG,FIN e ACk settati (!!!). Ma il metodo che mantiene
un buon compromesso di affidabilita' e 'discrezione' rimane il SYN scan.
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [NETW0RKiNG] #00 - 18/12/2000 |
| Butt Sniff 0.9 [Tritemius] 0x06/0x0E |
+-------------------------------------------------------------------------------+
iNTR0: iL D0GMA DELL0 SNiFFiNG
==============================
Butt Sniff e' uno sniffer, ovvero uno strumento in grado di intercettare i
dati in transito sul segmento fisico di una rete Ethernet. Questo articolo
si rivolge ai newbies, e ha lo scopo non solo di spiegare il funzionamento
di Ethernet (tecnologia ampiamente utilizzata nelle LAN, Local Area Network),
ma anche di introdurre alla scoperta del funzionamento della suite di
protcolli "tcp/ip", ovvero i "meccanismi" di base di Internet.
Alla fine della lettura si sara' in grado di leggere un log prodotto da
uno sniffer, di capire un po' meglio cosa succede quando "navighiamo" su
Internet. Inoltre ci si rendera' conto di quanto siano indifese le
informazioni in transito sulla rete locale, a meno che non siano prese le
adeguate contromisure. L'articolo' e' diviso in due parti: nella prima si
accennera' ai principi di networking (Ethernet,ISO/OSI,tcp/ip) e si introdurra'
il lettore all'utilizzo di ButtSniff. Nella seconda parte ("Il rituale dello
sniffing",pubblicata sul prossimo numero) verra' illustrato l'utilizzo pratico di ButtSniff e verranno
analizzati i log prodotti da questo programma, per comprendere meglio i
meccanismi di funzionamento del tcp/ip in pratica.
ETHERNET
========
Nata agli inizi degli anni '70 a Palo Alto al PARC (Palo Alto Research
Center) della Xerox, Ethernet diventa uno standard negli anni '80 grazie
agli sforzi di tre colossi del settore: DEC (Digital Equipment Corporation),
Intel a appunto Xerox: lo standard DIX (da DEC Intel e Xerox). Successivamente
DIX entro' a far parte degli standard IEEE (Institute of Electrical and
Electronics Engineers) con la sigla di IEEE 802.3 CSMA/CD. Oggi quando si
parla di "scheda di rete" in pratica si parla di una scheda Ethernet, e
le LAN (Local Area Network) di case, scuole, uffici si basano sul protocollo
Ethernet.
Il meccanismo di funzionamento di questo protocollo e' abbastanza semplice,
e la comprensione di questo meccanismo mostrera' subito in modo abbastanza
evidente qual'e' il problema dal punto di vista della sicurezza.
Iniziamo col chiariere che CSMA/CD sta per "Carrier Sense Multiple Access/
Collision Detection"; questo significa che tutti i computer della rete sono
collegati tramite un solo cavo su cui viaggiano i segnali (o comunque un
concentratore che smista i segnali verso tutti i computer); i controller
Ethernet controllano lo stato della linea; se la linea e' "sgombra" i dati
vengono inviati sul cavo e ricevuti da TUTTI i computer. Se la linea non
e' "libera", significa che due (o piu') controller hanno inviato dati
contemporanamente e si e' verificata una collisione. In questo caso tutti
i dispositivi smettono di trasmettere per alcuni istanti.
Ethernet invia insiemi di dati, chiamati "trame"; questi pacchetti hanno
un formato fisso:
8 byte di preambolo
6 byte con l'indirizzo fisico della scheda di rete di destinazione
6 byte con l'indirizzo fisico della scheda di rete d'origine
2 byte contenenti la lunghezza del campo dati
46/1500 byte campo dati
4 byte per il codice di controllo degli errori
Quello che voglio mettere in risalto, e' il fatto che le trame vengono
inviate a tutti i computer ma, in condizioni normali, la scheda di rete
accetta solo le informazioni che la riguardano, ovvero accetta quelle
trame che nel campo dell'indirizzo di destinazione contengono il proprio
indirizzo fisico.
Il problema e' che le schede di rete possono essere portate in "modalita'
promiscua", forzandole ad accettare tutte le trame trasmesse e non solo
quelle dirette alla scheda specifica. Lo sniffer fa appunto questo: abilita
la modalita' promiscua sulla scheda di rete e permette all'utente di "vedere"
tutto il traffico della rete, password e informazioni riservate comprese :)
Il Modello ISO/OSI
==================
"E' uno sporco lavoro, ma qualcuno lo deve pur fare"
Per completezza accenno al "Modello ISO/OSI", e al protocollo ARP (Address
Resolution Protocol).
Per "Modello ISO/OSI" (International Standards Organization, Open Systems
Interconnection) si intende uno schema (diviso in 7 "livelli") che illustra
il percorso che effettua l'informazione dallo stato piu' "basso" (hardware)
a quello piu' "alto", piu' "astratto", dove i segnali elettrici giungono a
noi sotto forma di immagini, suoni,testi.
I sette livelli ISO/OSI sono:
7 - Applicazione
6 - Presentazione
5 - Sessione
4 - Trasporto
3 - Rete
2 - DataLink
1 - Fisico
In realta' il modello tcp/ip puo' essere sintetizzato in 4 livelli:
4 - Applicazione
3 - Trasporto
2 - Rete
1 - DataLink
Per comprendere meglio questo modello, e' necessario spiegare cosa si intende
per "Applicazione", "Trasporto" eccetera.
Al "Livello 4", ovvero "Applicazione", corrispondo tutti quei protocolli che
conosciamo bene (almeno per "sentito dire"):http,smtp,pop3... Questi protocolli
vengono gestiti direttamente dall'applicazione (per esempio: il client di posta
elettronica, il browser...).
Il livello 3 ("Trasporto") corrisponde al tcp (Transmission Control Protocol)
e all'udp (User Datagram Protocol). Questi due protocolli servono appunto per
trasportare l'informazione attraverso Internet. Il tcp e' un protocollo
"orientato alla connessione" e affidabile: tcp instaura connessioni-virtuali
tra gli host, e si preoccupa che i dati non vengano dispersi nella rete; udp
non e' orientato alla connessione e non e' un protocollo "affidabile": i dati
a lui affidati possono essere dispersi senza alcun avviso. Di solito per
effettuare trasferimenti di dati si usa tcp (http,ftp,smtp...); mentre per
comunicazioni asincrone dove la mole di dati e' ridotta, si puo' usare udp
(le comunicazione client-to-client di ICQ usano udp). Non e' una regola fissa,
ma a grandi linee illustra le differenze tra i due protocolli di trasporto.
Il livello 2 e' il livello di rete: ip, ovvero Internet Protocol, il principe
dei protocolli Internet. Ip "incapsula" i protocolli visti sopra, gli assegna
gli indirizzi idonei (i famosi "indirizzi ip"),le "porte" e affida i pacchetti
alla rete. Questo protocollo ha un cugino meno famoso ma fondamentale:icmp,
ovvero Internet Control Message Protocol, protocollo Internet per i messaggi
di controllo. Quando effettuate un "ping" non fate altro che inviare un
particolare pacchetto icmp (icmp_echo).
L'utlimo livello e' "Datalink", ovvero il livello hardware: nel nostro caso
ethernet.
Un'ultima cosa prima di proseguire con Buttsniff. Com'e' che si associa
l'indirizzo fisico di una scheda all'indirizzo ip ? Come si trasforma
00-00-00-00-00-00 in 192.168.0.2 ? Tramite ARP (Address Resolution Protocol).
In pratica ARP fornisce una tabella dove all'indirizzo fisico viene associato
l'indirizzo ip.
BUTTSNiFF
=========
Veniamo a Buttsniff. Eseguendolo dalla linea di comando senza argomenti,
il programma ci presenta il seguente output:
Win32: Version 4.0 Build 1111 B
BUTTSniffer v0.9 (c) 1998, Cult of the Dead Cow
Usage: buttsniff -{idl} <arguments>
-i (interactive) arguments: <device name> <port>
-d (disk dump) arguments: <device name> <log file> <dump type> [filter]
-l (list devices) arguments: (none)
Valid dump types are:
e (raw ethernet) Dumps raw ethernet frames
i (decoded IP) Dumps decoded IP packets
p (full protocol) Dumps fully decoded protocol packets
Valid filters are:
A single number representing a port to be monitored (e.g. 80)
A port range to be monitored (e.g. 141-1024)
A filename containing a list of IP and port filter rules
Read the 'readme.txt' for more information and examples.
Filters are only active on dump type 'p'.
Analizziamo in dettaglio. Innanzitutto BS (da ora lo chiamero' cosi') ha tre
modalita' di funzionamento:
1) Modalita' interattiva (-i). BS viene "bindato" su una porta tcp; attivando
una connesione sulla suddetta porta (tramite telnet o netcat) ci trovamo di
fronte a un "pannello di controllo" dove
vengono visualizzate le connsessioni in corso sulla rete; in questa modalita'
BS "cattura" (e visualizza) automaticamente le password in transito.
2) Modalita' "Disk-dump" (-d): i pacchetti di dati vengono salvati in un file
specificato dall'utente; BS puo' loggare i pacchetti in tre formati: ethernet,
ip, "full-protocol". Dal punto di vista didattico il formato "full-protocol"
e' quello piu' interessante.
3) "LIst devices" (-l): in realta' questa non e' una "modalita'" di
funzionamento, ma e' semplicemente il comando che visualizza le schede
di rete disponibili sull macchina. In patica, piu' che di "scheda" si puo'
parlare di "interfaccia": anche il modulo di accesso remoto e' visto come
interfaccia di rete.
Eseguendo "buttsniff -l" sul mio sistema ottengo:
Win32: Version 4.0 Build 1111 B
Name: 0000 Description: Driver di Accesso remoto
Name: 0001 Description: 3Com EtherLink II o IITP (8 o 16-bit) (3C503)
Dove "Driver di Accesso Remoto" si riferisce alla mia connessione dial-up
con Internet tramite modem V.90 con protocollo ppp (Point-to-Point Protocol)
mentre "3Com Etherlink II o IITP (8 o 16-bit) (3C503)" e' la scheda collegata
alla mia rete privata.
Sia la modalita' interattiva, sia la "modalita' disk-dump" richiedono il
parametro <device name>, che non e' altro che il risultato di buttsniff -l.
Se volessi effettuare un diskdump del traffico che passa sulla rete privata
dovrei utilizzare 0001 come device name; se volessi controllare il traffico
in entrata-uscita da/verso Internet, dovrei utilizzare l'interfaccia associata
ad Accesso Remoto, ovvero 0000.
BS puo' generare tre tipi di loggin: "raw ethernet","decode ip",
"full protocol".
Il primo non e' altro che il pacchetto ethernet cosi com'e' l'ho descritto
nel paragrafo dedicato a ethernet. Per leggere questo log e' necessario
utilizzare un editor esadecimale, in quanto l'output e' binario.
"Decode ip" e' la rappresentazione del pacchetto ip: indirizzo sorgente
e destianzione, porte sorgente e destinazione, Type Of Service,
Checksum...
Questo e' lo schema dell'header del protocollo ip, cosi' come' descritto
in RFC 791:
A summary of the contents of the internet header follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Full protocol" mostra tcp con tutti i suoi parametri i flag, oppure icmp
con il tipo di pacchetto e i dati in esso contenuto.
Di seguito lo schema dell'header tcp (RFC 793):
RFC 793
TCP Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C0NCLUSi0Ni
===========
Il dogma dello sniffing e' giunto a compimento; nel prossimo numero vedremo
come funziona in pratica e come usare uno sniffer, e saremo in grado di
visualizzare il funzionamento del tcp/ip in modo dettagliato.
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [CRACKiNG] #00 - 18/12/2000 |
| PEditor 1.6 [-=AndreaGeddon=-] 0x07/0x0E |
+-------------------------------------------------------------------------------+
Trattato sul programma PEditor (v 1.6) e sul PEditing in generale.
Scritto per la E-Zine "Onda Quadra" del gruppo HackManiaci
Autore: -=AndreaGeddon=- [(-UIC-)] (e chi sennò!)
Logo:
________ _____ ___ ___ _____ ______ ________
/ __ /| / | / /| / \ / \ / ___/| / __ /|
/ /_/ / / / /| | / / / / / \ / /| | / /___|/ / /_/ / /
/ __ / / / / | |/ / / / / > / /| / __/| / __ / /
/ /|/ / / / / /| / / / / / / | / /| |/ / /__|/ / /|/ / /
/__/ /__/ / /__/ / |____/ / /____/ / /__/ |__| /______/| /__/ /__/ /
|__|/|__|/ |__|/ |____|/ |____|/ |__|/|__| |______|/ |__|/|__|/
_ _ _ _
(_.-'` `'-._.-'` `'-=* Reversers do it betteR ! *=-'` `'-._.-'` `'-._)
________ ______ ___ ___ _________ _____ ___
/ ______/| / ___/| / \ / \ / ___ /| / | / /|
/ /|_____|/ / /___|/ / / \ / / \ / /|_/ / / / /| | / / /
/ //_ /| / __/| / / > / / > / / // / / / / | |/ / /
/ //|/ / / / /__|/ / / / | / / / | / /_// / / / / /| / / /
/_______/ / /______/| /____/ / /____/ / /________/ / /__/ / |____/ /
|_______|/ |______|/ |____|/ |____|/ |________|/ |__|/ |____|/
. _
| | | /
|_| | \_
Puff puff... mi è sempre piaciuto disegnare in ascii... ma non sono molto bravo.
Oki inziamo.
-------------------------------------------------------------------------------------------------------+
-o DISCLAIMER |
-------------------------------------------------------------------------------------------------------+
Le informazioni presenti in questo testo sono a scopo puramente didattico. L'autore e l'E-Zine non si
ritengono responsabili dell'uso che farete di queste informazioni (e francamente se ne fregano).
-------------------------------------------------------------------------------------------------------+
-o OVERVIEW |
-------------------------------------------------------------------------------------------------------+
Ho trovato questo bellissimo programma, che è una sorta di ProcDump ma più evoluto e con molte più
funzioni. Ho pensato quindi di descriverne tuuutte le funzioni e di spiegare tutti i campi che ci
permette di modificare in un eseguibile. Ovviamente verranno spiegate anche la teoria del Manual
Unpacking e il formato PE, senza i quali la spiegazione del prog non starebbe in piedi. Man mano che
tratterò vari punti di questo programma, ne spiegherò anche la relativa teoria. Il seguente documento
inoltre può essere usato come riferimento per tutti i programmi di PE-Editing che volete.
--+-- INTRO -- Informazioni sull'uso del programma e sua reperibilità, accenni al formato PE.
|
+-- CENNI DI TEORIA SUL MEMORY MAPPING E SUL FORMATO PE
|
+-- LA SCHERMATA INIZIALE -- Commento degli header Optional & File e funzioni principali
|
+-- LA SEZIONE "SECTIONS" -- Vediamo le sezioni da vicino
| |
| +-- Relativo Menù del tasto destrto
|
+-- LA BARRA DEI COMANDI SULLA DESTRA
|
+-- LA SEZIONE "DIRECTORY" -- Accurata descrizione dell'import/export table etc...
|
+-- NOTE
|
+-- LIBRARY, THANKS, LINKS AND E-MAIL
-------------------------------------------------------------------------------------------------------+
-o INTRO |
-------------------------------------------------------------------------------------------------------+
A cosa serve il PEditor? Serve per manipolare file eseguibili del formato standard PE (Portable
Executable) della piattaforma Win32, ma è anche un potente Memory Tool che permette di dumpare i
processi che volete, ottenerne informazioni, killarli, etc. In pratica, molti dei maggiori sistemi di
protezione utilizzano la tecnica del Crypting (o Packing), che consiste nel criptare il file eseguibile
in modo da impedire agli smanettoni di andare a ficcare il naso nel programma per modificarlo a proprio
piacimento. Questi programmi si autodecriptano all'esecuzione, quindi si troveranno in memoria già belli
che decriptati, ed è la che arriviamo noi col PEditor: non dobbiamo fare altro che prendere il file
dalla memoria e salvarlo su disco, per ottenere una copia del file eseguibile già decriptata e
funzionante e pronta per essere manipolata da noi. Peccato che in realtà non è mai così semplice, visto
che spesso c'è bisogno di rimettere a posto alcune cosette per far partire il programma. Il PEditor se
ben usato ci permette di fare tutto questo.
Il programma lo trovate su Player's Tools:
http://playtools.cjb.net
gli autori sono M.O.D. e Yoda.
-------------------------------------------------------------------------------------------------------+
-o CENNI DI TEORIA SUL MEMORY MAPPING E SUL FORMATO PE |
-------------------------------------------------------------------------------------------------------+
Ogni file eseguibile ha una sua struttura ben precisa. Tale struttra varia a seconda della piattaforma
per la quale è stato scritto il software. Quella di cui ci interessemo qui è la struttra del PE, il
COFF (Common Object File Format) degli
eseguibili standard della piattaforma win32. Tale struttura ci
servirà anche per capire come il programma viene caricato in memoria. Vediamola in breve:
+------------------+
| DOS Header (MZ) |
+------------------+
| PE Header (PE) |
+------------------+
| Section Table |
+------------------+
| Sezione |
+------------------+
| Sezione n |
+------------------+
Gli header contengono le informazioni sul file eseguibile stesso, la section table contiene le
informazioni delle varie sezioni, e le sezioni sono i veri e propri blocchi di dati e codice accomunati
dalle stesse proprietà. Di solito ci sono delle sezioni standard, tipo:
.text o .CODE - Sezione di codice eseguibile
.data - Sezione di data
.rsrc - Sezione delle risorse, tipo bitmap, dialogs etc.
.reloc - Sezione della relocation table
e altre un pò meno comuni. Dare uno sguardo alle sezioni è sempre utile, non solo per farci un'idea del
programma, ma anche per ottenere preziose informazioni: insomma, se trovate la sezione .Shrink non avete
difficoltà a capire che avete a che fare con uno Shrinker :-).
Ora abbiamo una idea di come è fatto un file eseguibile PE, vediamo brevemente come viene caricato,
eseguito e mappato in memoria. Quando eseguiamo un file, il PE loader legge gli header (MZ e PE), da lì
legge le varie informazioni sul file che ci si sta apprestando a caricare (informazioni che ritroveremo
e spiegheremo in seguito), quindi le varie sezioni vengono mappate in memoria. In genere l'indirizzo di
inizio per la mappatura è di 00401000 per un eseguibile (cioè la sua image-base + CodeBase, vedi dopo).
Gli eseguibili protetti da packers o crypters sono leggermente diversi: il file fisico contiene le
sezioni criptate, quindi non possiamo andarle a disassemblare o modificare, a meno che non conosciamo
a priori l'algoritmo di crypting. Durante l'esecuzione il file si auto decripta e si mappa in memoria
già decriptato e funzionante. L'idea è quindi quella di copiare il contenuto della memoria (relativo al
file eseguibile decriptato) e salvarlo su disco. Otterremmo così senza sforzo il nostro eseguibile
decriptato. Come immaginate la cosa non è così semplice! Ci sono vari problemi che si incontrano nel
fare questa operazione (che viene chiamata "Dumping"): alcuni dovuti al SO, altri dovuti alla
bastardaggine dei programmatori che l'hanno implementato. Per esempio, il Windox usa il meccanismo della
paginazione per gestire la memoria, cioè le sezioni del file eseguibile vengono mappate a pagine di 4kb.
Il problema è che per risparmiare memoria non sempre sono presenti TUTTE le pagine del programma che
vogliamo dumpare (ad esempio alcune pagine sono state swappate sul disco), quindi usando il comando PAGE
del softice dovremmo andare a vedere la lista delle pagine con i relativi attributi Present/Not Present,
poi con il comando PAGEIN dovremmo caricare fisicamente in memoria le pagine non presenti. A quel punto
abbiamo in memoria il file completo e pronto per essere dumpato. Una volta dumpato poi il file ancora
non funzia, quindi dobbiamo andare a vedere cosa c'è che non va, e qui succedono i casini, perchè
bisogna vedere come hanno implementato i programmatori il sistema di Crypting: ad esempio una cosa molto
comune è la manomissione della Import Table. Addirittura si potrebbero anche incontrare problemi quando
si va a fare il PAGEIN. Ecco perchè andremo a studiarci il PEditor: conoscendo a fondo tutte ciò che ci
permette di fare il programma possiamo riuscire ad attaccare e risolvere i vari crypter.
-------------------------------------------------------------------------------------------------------+
-o LA SCHERMATA INIZIALE |
-------------------------------------------------------------------------------------------------------+
Quando avviate il PEditor vi appare la schermata iniziale con molti campi che corrispondono ognuno ad
un valore specifico. Caricate un programma eseguibile (io per esempio carico il WinZip32 v7.00) e
vedrete gli edit box riempirsi di numerelli :-). Commentiamoli tutti!
Piccola precisazione:
RVA = Relative Virtual Address, cioè indirizzo RELATIVO all'image base (del tipo 00001234)
VA = Virtual Address, cioè indirizzo virtuale che troviamo in memoria (del tipo 00401234)
Tenete Presente che in ogni campo del PEditor troveremo quasi sempre RVA, e questi valori non indicano
direttamente la posizione dell'oggetto nel file fisico. Per ottenere il vero offset bisogna calcolarselo
attraverso il FLC. In questo testo per comodità ho scelto programmi in cui l'rva coincide sempre con
l'offset fisico (fenomeno spiegato in seguito), però non dimenticate mai di considerare l'rva come un
valore che deve sempre essere convertito in file offset.
-- Entry Point --
Questo valore ci dà l'indirizzo fisico dell'Entry Point, cioè dell'indirizzo da cui il programma inizia
l'esecuzione. Nel mio caso è 00055C20. Ho detto indirizzo FISICO in quanto questo valore corrisponde
alla locazione nel file eseguibile, cioè al 55C20 = 351264-esimo byte ci sarà il punto dove il programma
deve iniziare l'esecuzione. L'indirizzo di memoria corrispondente sarà ottenuto sommando 55C20 al valore
datoci dall'Image Base (però non è sempre così), di cui parleremo fra poco.
-- Image Base --
Nel mio caso vale 00400000 ma praticamente quasi tutti gli eseguibili hanno questo valore. L'image base
non è altro che il valore da cui viene iniziata la mappatura del file eseguibile, cioè è l'indirizzo a
partire dal quale viene messo il file in memoria. Se debuggate spesso non avrete potuto fare a meno di
notare che nei file eseguibili le istruzioni che seguite si trovano sempre ad indirizzi tipo 004xxxxx.
Appunto questo valore ve lo dà l'image base. Tale valore cambia a seconda del formato dell'eseguibile,
cioè se EXE o DLL... etc. L'image base per le DLL per esempio è più vario, ma generalmente l'indirizzo è
del tipo X0000000, per i tipi SYS in genere è 00010000 etc.
-- Base of Code --
Qui trovo il valore 00001000. Anche questo è quasi sempre uguale per tutti gli eseguibili. La sezione di
codice di un eseguibile inizia all'indirizzo 00401000, che appunto è dato da Image Base + Base of Code.
-- Base of Data --
68000. Questo valore invece cambia di volta in volta. Infatti è dato dalla grandezza delle sezioni di
codice precedenti: nel caso del winzip abbiamo le sezioni .text e INIT_TEX che finiscono appunto
all'indirizzo 68000. Da qui in poi ci sono sezioni di dati.
-- Size of Image --
La grandezza dell'immagine, cioè la grandezza che verrà mappata in memoria. Nel mio caso è FA000, che
corrisponde a 1'024'000. Il size fisico dell'eseguibile è invece di 983'040 bytes. Questa differenza è
data dal fatto che gli eseguibili devono rispettare dei valori di allineamento (che vederemo dopo), sia
per gli indirizzi VA (in memoria), sia per l'allineamento FISICO nel file (vedi Section Alignment e File
Alignment). Tali valori di allineamento significano che una sezione può iniziare e finire solo ad un
indirizzo che sia un multiplo del valore di allineamento.
-- Size of Headers --
Come intuibile, ci indica la grandezza degli headers (MZ+PE) e della Object Table (la table che descrive
le sezioni). Se questo valore è = a 1000 avremo un allineamento perfetto tra Virtual Offset e Raw
Offset, cioè VA - Image Base = Offset fisico (perchè la mappatura delle sezioni in memoria inizia da
00401000!). Se invece il size è diverso da 1000, allora per calcolarci l'offset fisico dobbiamo usare
la formula: VA - Image Base - Base of Code + Size of Headers = Offset Fisico.
-- Section Alignment --
Nel mio caso (ma molto spesso) 1000. Le sezioni vengono mappate in memoria secondo multipli di questo
valore. Per esempio, se una sezione è grande 1234, in memoria non verrà mappata uno spazio di 1234 ma
uno spazio di 2000 (primo multiplo di 1000 dopo 1234). Quando arrivo alla sezione sulle sezioni (sorry)
farò alcuni esempi e vedrete che capirete al volo.
-- File Alignment --
Come prima, solo che questo allineamento è relativo al file fisico. Anche nel file fisico le sezioni
vengono scritte a multipli di questo valore (che di solito è 200, ma varia parecchio). Ovviamente se
mettiamo un valore di allineamento troppo grande, sprecheremo dello spazio nel file fisico.
-- SubSystem --
Il sistema richiesto dal programma. Nel mio caso 0002. Questo campo può avere i seguenti valori:
0000h __Unknown
0001h __Native
0002h __Windows GUI
0003h __Windows Character
0005h __OS/2 Character
0007h __Posix Character
-- Machine Type --
Il tipo di macchina per cui è stato scritto il sw. Nel mio caso 14C. I valori di questo campo sono:
0000h __sconosciuto
014Ch __80386
014Dh __80486
014Eh __80586
0162h __MIPS Mark I (R2000, R3000)
0163h __MIPS Mark II (R6000)
0166h __MIPS Mark III (R4000)
quindi il programma in esame girerà su tutte le macchine 386+.
-- Number of Sections --
Indovinate ???????
-- Time Date Stamp --
Data e ora dalla creazione del file (creazione fatta dal linker).
-- Pointer To Symbol Table --
Usato per il debugging.
-- Number of symbols --
Usato per il debugging.
-- Size of Optional Header --
L'optional header è quello contiene le informazioni di Base of code, Size of Image etc. Questo campo vi
dice il suo size (nota che l'optional header però non contiene solo i campi che vediamo dal PEditor)
-- Characteristcs --
Contiene vari flag, ad esempio per specificare se il PE considerato è una DLL o un EXE.
-------------------------------------------------------------------------------------------------------+
-o LA SEZIONE DELLE SEZIONI |
-------------------------------------------------------------------------------------------------------+
Nella schermata iniziale c'è un pulsante etichettato "Sections". Premetelo e vi aprirà la finestra con
la lista e descrizione delle sezioni. Io ad esempio carico il 5° corso newbies di Quequero, e mi si
presenta la seguente tabella:
---------+--------------+----------------+----------+------------+-----------------
Section | Virtual Size | Virtual Offset | Raw Size | Raw Offset | Characteristics
---------+--------------+----------------+----------+------------+-----------------
.text | 0000322B | 00001000 | 00003400 | 00000400 | 60000020
.rdata | 000007F6 | 00005000 | 00000800 | 00003800 | 40000040
.data | 000008E4 | 00006000 | 00000800 | 00004000 | C0000040
.idata | 000009BA | 00007000 | 00000A00 | 00004800 | C0000040
.rsrc | 00000854 | 00008000 | 00000A00 | 00005200 | 40000040
.reloc | 00000430 | 00009000 | 00000600 | 00005C00 | 42000040
---------+--------------+----------------+----------+------------+-----------------
Bella vero? Qui troviamo tutte le informazioni sulle sezioni.
-- Section --
IL primo campo (Section) ci dice il nome
delle varie sezioni. Di solito iniziano con un ".", ma non è sempre così. Il nome delle sezioni spesso
è anche relativo al contenuto: "text" indica una sezione di codice (anche .CODE), .data o simili indicano
sezioni di dati, .rsrc indica la sezione delle risorse (bitmap, icone, dialogs etc...), .reloc indica la
sezione delle Rilocazioni (è questa la traduzione di Relocations?). Qui è il caso di spendere due parole
sulle rilocazioni. Premetto che in un file eseguibile questa sezione è completamente inutili, visto che
nel 99% dei casi un eseguibile non subisce MAI una rilocazione. Ma cos'è una rilocazione? E' un fenomeno
che troviamo spesso nelle DLL. Quando un processo carica una dll, il codice della dll viene mappato su
un certo indirizzo xxx. Se però il programma carica diverse dll, si troverà a mappare di nuovo al tale
indirizzo xxx, dove è già presente una dll. Quindi il sistema operativo deve caricare questa dll in un
altro indirizzo yyy. A causa di questa rilocazione anche tutti i puntatori della dll vengono spostati!
Per esempio se normalmente avete una definizione di una stringa, in asm vedrete che il puntatore a questa
stringa sarà 00401234. Quando la dll verrà mappata, all'indirizzo 00401234 troverete la stringa. Se però
la dll è stata rilocata, anche questo indirizzo verrà cambiato per puntare alla stringa mappata nel nuovo
spazio yyy. Bene, la sezione .reloc contiene tutti questi indirizzi fissi, così quando la dll viene
caricata, il sistema operativo controlla questi indirizzi; se sono già occupati in memoria (da una dll
precedente) allora li alloca da un'altra parte. Detto così può sembrare un discorso campato in aria, ma
quando vi trovate a dover patchare delle dll le rilocazioni vi provocano problemini non indifferenti!
-- Virtual Size --
Questi valori indicano la grandezza reale della sezione in memoria. Ad esempio la sezione .text risulta
grande 322B bytes. Nota che questi valori sono REALI, e non soddisfano nessun allineamento.
-- Virtual Offset --
Indica l'RVA a partire dal quale sarà mappata in memoria la sezione. Per la sezione .text il valore è di
1000 e non zero. Perchè? Perchè questo 1000 è il famoso "Base of code". Quindi la prima sezione (.text)
partirà dal VA 00401000. Adesso ritorniamo al discorso degli allineamenti. Per la sezione .text io parto
da 00401000 e mappo 322B bytes. Quindi essendo le sezioni contigue, dovrei aspettarmi la prossima
sezione mappata da 00401000 + 322B = 0040422B. Il valore di allineamento delle sezioni, però, qui è di
1000, quindi la prossima sezione comincerà dal primo multiplo di 1000 disponibile dopo 0040422B, cioè
al VA 00405000 (RVA = 5000). E così via tutte le sezioni. L'ultima sezione comincia all'RVA 9000 ed è
lunga 430 bytes. Quindi in tutto l'ultimo byte sarà il 9430°. Sempre per l'allineamento, la fine di
questa sezione va a finire a A000, che è il valore del Size Of Image.
-- Raw Size --
La grandezza che le sezioni occupano nel file fisico. Anche questo valore è correlato ad un allineamento,
quello dato da File Alignment, che di solito è pari a 200. In effetti tutti i size sono multipli di 200.
La prima sezione ad esempio abbiamo visto che VIRTUALMENTE è grande 322B. Il primo multiplo di 200
disponibile dopo tale valore è 3400, quello del raw size. Lo spazio che va da 322B a 3400 viene riempito
con taanti zeri (469 decimale per l'esattezza). Bene, immaginate che questo si ripete per tutte le sezioni
di tutti gli eseguibili (e tutti i file con formato PE) che avete sull'HD! Già! Avete un hard disk pieno
di inutili zeri! Che ci volete fare...
-- Raw Offset --
L'indirizzo fisico dal quale è mappata la sezione nel file. Nel nostro caso per la sezione .text abbiamo
un offset di 400 e non di zero. 400 infatti è il valore che ritroviamo in "Size of Headers". Quindi gli
header MZ+PE sono grandi 400 bytes, e da qui inizieranno le sezioni. La raw size di .text è 3400, quindi
la prossima sezione sarà a 3400+400 = 3800. Come vedete qui tutto combacia con l'allineamento a 200.
A questo punto prendiamo il raw offset dell'ultima sezione (5C00), aggiungiamogli il raw size dell'ultima
sezione (600). Risultato: 6200. Aggiungiamo ancora 200 (del file alignment) e otteniamo 6400, che in
decimale vale 25600, esattamente il valore della grandezza del file fisico.
-- Characteristcs --
Questo campo descrive il tipo di sezione (dati, eseguibile, etc.). I valori possono essere i seguenti
000000020h Sezione di codice
000000040h Sezione di dati inizializzati
000000080h Sezione di dati non inizializzati
040000000h La sezione non deve essere messa in cache
080000000h La sezione non è paginabile
100000000h La sezione è condivisa
200000000h Sezione eseguibile
400000000h Sezione in lettura
800000000h Sezione in scrittura
e possono essere combinati. Ad esempio la sezione .text ha il valore 60000020, che è una combinazione di
000000020 + 40000000 + 20000000, cioè Sezione di codice, eseguibile e leggibile. La sezione .data,
invece, è una combinazione di 80000000 + 40000000 + 00000040, cioè dati inizializzati, lettura e
scrittura. Questi attributi sono molto importanti perchè ci danno un idea precisa delle sezioni che
abbiamo davanti.
--== IL MENU' DEL TASTO DESTRO ==--
Se cliccate col destro su una sezione avrete il segente menù:
>>Edit Section
Vi aprirà un nuovo DialogBox con tutti i campi della sezione, e ve li potrete modificare a vostro
piacimento. Notate il tasto Char Wizard: questo apre una apposia finestra che vi permette di modificare
automaticamente le flag di "Characteristcs".
>>Add a section in the PE Header
Per aggiungere una sezione.
>>Delete the section in the PE Header
Per cancellare la sezione selezionata.
>>Copy the section to HD
Salva la sezione in un file su HD.
>>Move the section to HD
Salva la sezione su HD e poi la cancella dall'eseguibile.
>>Copy a section from HD to EOF
Prende una sezione salvata su disco e la inserisce alla fine del file (dopo le altre sezioni).
>>DumpFixer (RS=VS & RO=VO)
Dopo aver unpackato un file eseguibile molto probabilmente dovrete rimettere a posto i valori Size e
Offset sia Virtuali che Raw. Prima ce lo facevamo a parte col procdump, ora con il PEditor è automatico!
Questa operazione si chiama "Riallineamento del PE", e a questo punto dovrebbe esservi chiaro perchè
dobbiamo farla: dopo aver dumpato un programma è probabile che le sezioni contengano dei dati non giusti
sulla Raw Size; infatti dopo che avete unpackato il file, le sezioni risultano più grandi di quanto lo
erano prima nel file fisico compresso, quindi dobbiamo cambiare i relativi descrittori.
>>Set the characteristics to E0000020
Setta automaticamente le flag della sezione a CODICE, ESEGUIBILE, LETTURA, SCRITTURA.
>>Truncate at the start of this section
Cancella tutti i byte dalla sezione selezionata in poi.
>>Custom truncate
Cancella tutti i byte da un offset specificato in poi.
-------------------------------------------------------------------------------------------------------+
-o LA BARRA DEI COMANDI SULLA DESTRA |
-------------------------------------------------------------------------------------------------------+
Descriviamo ora i comandi (quelli in colonna a destra).
-- Browse --
Se questo non l'avete capito da soli spegnete il pc e dategli fuoco.
-- Tasks --
L'elenco dei task in esecuzione. Per ogni task avete i dati, cioè Process ID, Image Base, Size of Image
e Owner. Premendo su un task con il tasto destro avrete il seguente menù:
+--------------------+
| dump (full) |
| dump (partial) |
| dump (Sections) |
+--------------------+
| view process infos |
| load into PEditor |
+--------------------+
| terminate process |
+--------------------+
| refresh |
+--------------------+
>> dump full: vi permette di dumpare l'intero processo in automatico
>> dump partial: vi permette di dumpare una area di memoria a piacimento, scegliendo gli offset iniziale
e finale del dump.
>> dump sections: apre un dialogbox in cui avete una lista delle sezioni che potrete dumpare
separatamente, compreso l'header PE.
>> view process infos: apre un dialog che contiene i seguenti campi:
Usage
Th32ProcessId
Th32DefaultHeapId
Th32ModuleId
CntThreads
Th32ParenProcessId
PcPriClassBase
>> load into PEditor: attenzione per gli assuefatti al ProcDump! Questa opzione carica solo il file exe
relativo al processo, e non i dati relativi al processo stesso! Cioè, in procdump voi con process
infos caricavate le info sulle sezioni a runtime, con PEditor invece non potete.
>> terminate process: killa un processo
>> refresh: refresha tutti i valori
-- ! --
Refresha tutti i valori di tutti i campi.
-- Section Split --
Dumpa in automatico tutte le sezioni separate, ognuna in un file diverso che verrà messo nella dir
corrente. Attenzione perchè non vi viene chiesta nessuna conferma!
-- Break'n Enter --
Questa funzione serve per breakare su un indirizzo qualsiasi di un programma. Come funziona? Per esempio
prima andavamo a scriverci a mano un CCh all'indirizzo per trapparlo con softice tramite BPINT 3, ora con
break'n enter settiamo un BPINT 3 da softice, premiamo il tasto RUN e popperemo direttamente sullo
indirizzo. Non solo! In sice avremo nella prompt window un riquadro che ci dice che byte dobbiamo
ripristinare all'indirizzo al posto del CC! Non è stramitico ??!!
-- FLC --
Sta per File Location Calculator. Praticamente vi richiede un valore che può essere uno dei seguenti
campi: VA, RVA, Offset esadecimale, Offset decimale; tale valore verrà convertito negli altri campi
e vi vengono pure indicati i primi bytes che si trovano all'offset in quel file.
-- Checksum --
Calcola il checksum corretto del file e vi dice quale è invece il checksum attualmente memorizzato nel
file (di solito 0). C'è anche la possibilità di correggereil checksum in automatico tramite l'apposito
tasto "correct it".
-- Rebuilder --
Il rebuilder serve per ricostruire (o meglio, provare a ricostruire) la import table. Spesso dopo il
dump un programma può avere la Import Table (IT) compromessa, quindi per far funzionare l'eseguibile
dumpato avremo bisogno di ricreargli la IT. Questa cosa si può fare in diversi modi, e il Rebuilder è
uno di questi! La comodità del rebuilder è che lo fa in automatico, però non sempre riesce (anzi, io
finora non sono mai riuscito a ricostruire una IT semplicemente col rebuilder). Cmq vediamo come funzia:
O-O Wipe Relocation Section
Questa opzione permette di eliminare la Relocation Section, permettendo così direcuperare un pò di
spazio. La sezione Relocation negli eseguibili, come abbiamo visto, è praticamente inutile, visto che
gli eseguibili non subiscono mai le rilocazioni.
O-O Realign File (Only Win 9x)
Normal: Riduce il valore di allineamento del file, in modo da guadagnare spazio.
HardCore: Elimina anche il Dos Stub (una parte dell'header MZ, in genere quella che contiene il
messaggio "Questo prog ha bisogno di winzozz...) per guadagnare ancora altro spazio.
Notate che la riduzione di spazio ottenuta con il riallineamento non è sempre significativa.
O-O Rebuild Import Table
Fast: Cerca nell'import table le stringhe delle funzioni importate.
Carefully: Cerca nell'intero file le stringhe delle funzioni importate.
Force functionsearching: Forza la ricerca nell'intero file delle stringhe delle funzioni importate
anche se c'è già l'OriginalFirstThunk.
Nota-- Il discorso del table rebuilding è abbastanza complesso, qui ho dato solo la semplice
descrizione delle opzioni, i dettagli della Import Table verranno approfonditi più avanti nella
Sezione Directory/Imports.
Make PE Header Win NT/2k compatible: cerca di rendere il file compatibile con il Win NT controllando
il Size of Image, il File Size, Null Sections e fa il Section Overlap (boh!).
ecco fatto. Ora scegliete le opzioni più opportune e provate a ricostruire tutte le IT che volete. Vi
ricordo che se possibile le IT è meglio ricavarle in fase di dumping, o con il ProcDump (Rebuild New IT)
o ve la dumpate a mano. E' possibile che vi ritroverete ad aver aggiustato una IT, e scoprirete che il
file dumpato e riparato funzionerà solo sul vostro PC. Anche questo spiacevole inconveniente verrà
approfondito più avanti quando parleremo della IT.
-- Apply changes --
Se avete modificato un valore, con questo pulsante potete fare l'update.
-- About --
La finestra di about :-) Notate tra i ringraziamenti il nome del nostro caro Kill3xx!
-- Exit --
Indovinate ?
-------------------------------------------------------------------------------------------------------+
-o LA SEZIONE DIRECTORY |
-------------------------------------------------------------------------------------------------------+
Nella schermata principale avete il pulsante "Directory". Se ci cliccate verrà aperto un nuovo dialog
pieno di nuove funzioni e valori da commentare (gasp! ma quando finisce 'sto testo??). Questa sarà la
parte più difficile e importante, visto che parleremo della Import/Export Table e dei problemi connessi.
Cominciamo dal trafiletto di dwords: per ogni campo abbiamo sia RVA che SIZE. RVA ci dà l'indirizzo di
mappatura dell'oggetto in considerazione, SIZE ci dà la grandezza dell'oggetto stesso. In questa ultima
versione del PEditor hanno anche aggiunto i tips, tenete il mouse su un campo e vi dirà la posizione
fisica all'interno del file. Per esempio nel WinZip 8, vado sul campo Import Table e mi appare il tip:
"position of this entry: 00000170h (e_lfanew + 80h) related to: .rdata"
dove e_lfanew è un membro della struttura IMAGE_DOS_HEADER, membro che contiene il puntatore all'header
PE. 80h è la posizione del puntatore all'IT all'interno della struttura Directory, e related to .rdata
vuol dire che il VA si trova all'interno della sezione rdata (ehm.. questi tips stanno anche nella
schermata principale, avevo dimenticato di menzionarli :-)).
-- Export Table --
Nel programma in esame (WinZip 8) questo campo ha valori nulli. Di solito un exeguibile non ha delle
funzioni esportate. Per avere un esempio sottomano prendiamo il file Wz32.dll dalla dir del winzip.
Ora per la Export Table avremo l'RVA 0002FC60 e il SIZE 0000000149. Siccome siamo curiosi prendiamo un
hex-editor e andiamo a vedere con i nostri occhi questa esprt table. Carichiamo il wz32.dll, quindi
prendiamo l'rva 0002FC60 e col FLC lo convertiamo in raw offset. In questo caso il raw offset coincide
con 2FC60, a causa del perfetto allineamento. Ecco cosa troviamo:
02FC60 00 00 00 00 - E4 EE FD 38 - 00 00 00 00 - 0A FD 02 00 ................
02FC70 01 00 00 00 - 0D 00 00 00 - 0D 00 00 00 - 88 FC 02 00 ................
02FC80 BC FC 02 00 - F0 FC 02 00 - C0 83 01 00 - 60 83 01 00 ................
02FC90 50 83 01 00 - 46 E9 00 00 - E0 E8 00 00 - 10 72 01 00 ................
02FCA0 70 71 01 00 - A0 9C 01 00 - 80 97 01 00 - 60 C9 01 00 ................
02FCB0 00 C9 01 00 - 10 BF 01 00 - B0 C9 01 00 - 13 FD 02 00 ................
02FCC0 22 FD 02 00 - 32 FD 02 00 - 37 FD 02 00 - 42 FD 02 00 ................
02FCD0 52 FD 02 00 - 58 FD 02 00 - 63 FD 02 00 - 67 FD 02 00 ................
02FCE0 70 FD 02 00 - 81 FD 02 00 - 90 FD 02 00 - 99 FD 02 00 ................
02FCF0 00 00 01 00 - 02 00 03 00 - 04 00 05 00 - 06 00 07 00 ................
02FD00 08 00 09 00 - 0A 00 0B 00 - 0C 00 77 7A - 33 32 2E 64 ..........wz32.d
02FD10 6C 6C 00 44 - 72 61 67 41 - 70 70 65 6E - 64 46 69 6C ll.DragAppendFil
02FD20 65 00 44 72 - 61 67 43 72 - 65 61 74 65 - 46 69 6C 65 e.DragCreateFile
02FD30 73 00 57 5A - 35 36 00 75 - 6E 63 6F 6D - 70 72 65 73 s.WZ56.uncompres
02FD40 73 00 75 6E - 63 6F 6D 70 - 72 65 73 73 - 5F 69 6E 69 s.uncompress_ini
02FD50 74 00 75 6E - 7A 69 70 00 - 75 6E 7A 69 - 70 5F 69 6E t.unzip.unzip_in
02FD60 69 74 00 7A - 69 70 00 7A - 69 70 5F 69 - 6E 69 74 00 it.zip.zip_init.
02FD70 7A 69 70 6C - 61 62 65 6C - 44 69 73 6B - 65 74 74 65 ziplabelDiskette
02FD80 00 7A 69 70 - 6D 65 6D 63 - 6F 6D 70 72 - 65 73 73 00 .zipmemcompress.
02FD90 7A 69 70 73 - 70 6C 69 74 - 00 7A 69 70 - 77 69 70 65 zipsplit.zipwipe
02FDA0 44 69 73 6B - 65 74 74 65 - 00 Diskette.
(nota che sono riportati nella notazione intel, quindi ad esempio la seconda dword non è E4EEFD38 ma
il suo contrario 38FDEEE4)
questi sono i 329 Bytes della Export Table (149h, il Size). Come vedete la seconda metà è piena di
quelli che sembrano i nomi delle funzioni. Okei, diamo un significato a questa manciata di bytes.
La Export Table è strutturata nel modo seguente:
1. Directory Table (informazioni sulla ET stessa) (prime 10 dwords)
2. Address Table (puntatori alle funzioni nella dll)
3. Name Pointer Table (puntatori ai nomi delle funzioni)
4. Ordinal Table (struttura ordinale delle funzioni)
5. Name Strings (nomi delle funzioni)
bene, abbiamo tutti i dati per interpretare la nostra ET. Partiamo dalla Directory Table, che è formata
dalle prime 10 dwords, che identificano la struttra seguente:
___________________________________________________________________
VALORE | DWORD NELLA ET DI ESEMPIO |
------------------------------------+-----------------------------+
EXPORT FLAGS | 00 00 00 00 1° |
TIME/DATE STAMP | E4 EE FD 38 2° |
MAJOR VERSION | MINOR VERSION | 00 00 | 00 00 3° |
NAME RVA | 0A FD 02 00 4° |
ORDINAL BASE | 01 00 00 00 5° |
# EAT ENTRIES | 0D 00 00 00 6° |
# NAME PTRS | 0D 00 00 00 7° |
ADDRESS TABLE RVA | 88 FC 02 00 8° |
NAME PTR TABLE RVA | BC FC 02 00 9° |
ORDINAL TABLE RVA | F0 FC 02 00 10° |
------------------------------------+-----------------------------+
()- Export Flags: attualmente questo valore non è mai usato, sta sempre settato a zero.
()- Time/Date Stamp: data e ora di creazione dell'export.
()- Major/Minor version: due words che raramente sono usate.
()- Name RVA: punta alla stringa che rappresenta il nome della DLL
Nel nostro caso punta a 0002FD0A, che è l'indirizzo della stringa wz32.dll (contare per credere).
()- Ordinal Base: indica il numero di partenza della EAT (export address table), normalmente è a 1.
()- # EAT Entries: il numero delle funzioni esportate (nel nostro caso 0D = 13dec).
()- # Name Ptrs: indica il numero di funzioni nella Name Ptr Table, cioè abbiamo 13 nomi di funzioni.
Non sempre questo valore coincide con il numero dell funzioni effettivamente presenti nella ET.
Indica solo il numero dei NOMI delle funzioni esportate.
()- Address Table RVA: indica la struttra che contiene i puntatori al codice delle funzioni.
Nel nostro caso punta alla seguente struttura:
02FC88 C0 83 01 00 - 60 83 01 00 ................
02FC90 50 83 01 00 - 46 E9 00 00 - E0 E8 00 00 - 10 72 01 00 ................
02FCA0 70 71 01 00 - A0 9C 01 00 - 80 97 01 00 - 60 C9 01 00 ................
02FCB0 00 C9 01 00 - 10 BF 01 00 - B0 C9 01 00 ............
Come vedete sono tutti puntatori (RVA) a zone di codice precedenti a quella della ET. Ad esempio
avremo che la prima dword 000183C0 identifica l'RVA del codice che effettivamente contiene la
prima funzione esportata, la seconda dword 00018360 identifica il puntatore alla seconda funzione
effettiva di codice e così via.
()- Name ptr table RVA: indica la struttura che contiene i nomi delle funzioni importate.
Nel nostro caso punta a 0002FCBC, che è la seguente struttura:
02FCBC 13 FD 02 00 ................
02FCC0 22 FD 02 00 - 32 FD 02 00 - 37 FD 02 00 - 42 FD 02 00 ................
02FCD0 52 FD 02 00 - 58 FD 02 00 - 63 FD 02 00 - 67 FD 02 00 ................
02FCE0 70 FD 02 00 - 81 FD 02 00 - 90 FD 02 00 - 99 FD 02 00 ................
Anche questi sono puntatori (sempre RVA) ai nomi delle funzioni esportate, prendiamo la prima
dword: 0002FD13 punta alla stringa "DragAppendFile" che è il nome della prima funzione esportata,
la seconda dword punta a 0002FD22, cioè la stringa "DragCreateFiles", e così via per tutte e 13
le funzioni esportate.
()- Ordinal Table RVA: indica la struttura degli Ordinali (li vedremo fra poco).
Di nuovo vediamo che punta a 02FCF0, ecco cosa ci trovate:
02FCF0 00 00 01 00 - 02 00 03 00 - 04 00 05 00 - 06 00 07 00 ................
02FD00 08 00 09 00 - 0A 00 0B 00 - 0C 00 ................
i numeri da 0000 a 000C (gli ordinali delle 13 funzioni). Beh, prima vi ho tenuto in sospeso sul
fatto di questi ordinali, ora è il momento di fare luce! Le funzioni possono essere esportate
tramite i nomi, come in questo caso, o anche soltanto tramite i loro numeri ordinali, senza dover
usare i nomi. Sicuramente vi sarà capitato di debuggare qualche programma che nella sua Import
Table non ha nomi di funzioni carini tipo "CheckTheSerial" o "CheckIfCdIsCopied", ma avrete solo
quei noiosissimi "Ordinal 0160h" e così via. Questo è dovuto proprio al fatto che il programma fa
riferimento a una libreria che ha le export in Ordinal Only. Il programma identifica le funzioni
da richiamare semplicemente dal numerello a 16 bit (assegnato univocamente a ogni funzione),
numero che viene appunto usato da GetProcAddress per ricavarsi l'indirizzo della funzione voluta.
-- Import Table --
Se fin qui gli argomeni trattati vi sono sembrati difficili, spegnete il computer e andate a giocare con
le macchinine (o con le bambole), perchè stiamo per affrontare l'argomento più ostico di tutto questo
testo, e francamente anche il più importante, quello che vi ritroverete spesso a dover fronteggiare
quando ingaggerete battaglie disperate con crypters assurdi. Cmq fin qui è stato tutto facile, giusto?
Vedrete che alla fine se spiegato bene anche questo argomento diventerà facile come gli altri.
Tanto per cominciare mi serve una cavia adatta: qual'è un file con una IT semplice che abbiamo tutti?
il Notepad.exe! Andiamo nella Directory Table e per la IT troviamo:
Import table: RVA: 00006000 SIZE: 8C
quindi abbiamo indirizzo e grandezza. Ora 6000 è un RVA, quindi col FLC andiamocelo a convertire in raw
offset, ed otteniamo... 6000 (allineamento perfetto).
B0 61 00 00 - ED 6C 45 37 - FF FF FF FF - 8A 65 00 00
F0 63 00 00 - 18 61 00 00 - B3 C2 1F 37 - FF FF FF FF
9C 67 00 00 - 58 63 00 00 - CC 61 00 00 - EB 6C 45 37
FF FF FF FF - 92 6B 00 00 - 0C 64 00 00 - B8 60 00 00
72 C2 3E 35 - FF FF FF FF - F6 6C 00 00 - F8 62 00 00
C0 62 00 00 - ED 6C 45 37 - FF FF FF FF - 7A 6D 00 00
00 65 00 00 - A0 60 00 00 - EB 6C 45 37 - FF FF FF FF
DA 6D 00 00 - E0 62 00 00 - 00 00 00 00 - 00 00 00 00
00 00 00 00 - 00 00 00 00 - 00 00 00 00
questi sono i 140 (8Ch) bytes. Per ora non compaiono nomi di funzioni o dll.
Partiamo dalla Directory Table, che come al solito contiene le informazioni sulla IT stessa. Dobbiamo
prendere in considerazione le prime 5 dwords, che ci identificano i seguenti valori:
_____________________________________________________________________________
VALORE: | DWORD NELLA IT DI ESEMPIO |
--------------------------------------------+-------------------------------+
Union: IMPORT FLAGS or OriginalFirstThunk | B0 61 00 00 |
TIME/DATE STAMP | ED 6C 45 37 |
FORWARDER CHAIN | FF FF FF FF |
NAME RVA | 8A 65 00 00 |
IMPORT ADDRESS TABLE RVA (FirstThunk) | F0 63 00 00 |
--------------------------------------------+-------------------------------+
anche le dword successive vanno considerate a gruppi di 5, compreso l'ultimo gruppo di 5 dwords che
serve per chiudere la Directory dell'IT.
()- Import Flags
Questo dovrebbe rientrare nel campo "characteristics", ma in realtà la dword è una union tra il valore
Characteristics e OriginalFirstThunk. Essendo il campo characteristics sempre a zero, la dword contiene
il valore dell'OriginalFirstThunk, 000061B0, che punta alla struttura degli indirizzi ai nomi delle
funzioni importate:
7A 65 00 00 - 68 65 00 00 - 20 65 00 00 - 4E 65 00 00
3C 65 00 00 - 2E 65 00 00 - 00 00 00 00
questi valori dunque puntano ai nomi delle funzioni (la NULL indica il termine della struttura), e
questi indirizzi di nomi faranno parte degli OriginalFirstThunk (ne parleremo dopo).
E le Characteristics? La union è come una struttura, solo che i membri di tale struttura possono essere
utilizzati solo uno alla volta. Quindi il la union in questione può contenere O le characteristics O
OriginalFirstThunk. Notate che sono 6 funzioni importate, e che l'ordine dei loro nomi non coincide con
l'ordine dei loro puntatori (cosa che noterete se andate a vedere l'IT dal PEditor).
In realtà questi indirizzi sono dei puntatori ad altre strutture, cioè:
Struttura IMAGE_IMPORT_BY_NAME:
word HINT
byte NAME1
infatti prendiamo ad esempio il primo puntatore, 0000657A, punta alla stringa:
0000657A 6C 00 53 68 65 6C 6C 45 78 65 63 75 74 65 41 00 l.ShellExecuteA
in cui i primi due byte sono la word HINT (006C) che rappresenta l'indice della funzione nell'ET della
dll da cui stiamo importando la funzione, e poi il nome vero e proprio, ShellExecuteA in forma di array
di byte terminati dallo 0.
()- Time Date Stamp
La solita dword con la data e ora di creazione della IT.
()- Forwarder Chain
Nel nostro caso è settato a -1, e quindi non ci sono forwarders. Cos'è un forwarder? Una dll può
esportare un simbolo che non è definito nella dll stessa, ma è importato da un'altra dll. In tal caso
il simbolo si dice Forwarded. Ora sorge il problema che nel FirstThunk di un Forwarded noi abbiamo
l'entry point della funzione, però il loader non ha modo di verificare se questo entry point è corretto
dato che non si trova realmente nella dll da cui stiamo importando. Quindi l'entry point dell forwarded
deve essere sempre fixato, e tale fix può avvenire tramite il ForwarderChain. Lo troviamo come indice
nella lista dei thunks, in cui la funzione alla posizione indicizzata è una funzione esportata in
forward, e il FirstThunk a tale posizione è l'indice della prossima funzione importata. La catena
continua fino a trovare il valore -1, che indica che non ci sono più forwarders.
()- Name RVA
Questo punta al nome della dll importata. Abbiamo un bel 0000658A. Andiamo a cercare anche questo rva
nel file (non serve la conversione in raw offset perchè come abbiamo visto l'allineamento è perfetto) e
ci troviamo la stringa:
0000658A 53 48 45 4C 4C 33 32 2E 64 6C 6C 00 SHELL32.dll
()- Import Address Table RVA
Abbiamo il valore 000063F0. Questo valore punta ad un array di dwords, l'ultima delle quali è nulla ed
indica la fine della tabella.
Nel nostro caso a 000063F0 troviamo:
FF 6A D1 7F - 0F 28 CD 7F - 66 16 CE 7F - 7C 84 CB 7F
EB C6 CC 7F - 7B 42 D1 7F - 00 00 00 00
6 dowrd più l'ultima NULL. Queste dwords ci danno gli indirizzi delle funzioni importate per ogni dll,
però non le import all'interno del file (OriginalFirstThunk), ma delle import functions vere e proprie
(FirstThunk).
Ho come l'impressione di non essere stato molto chiaro. Allora continuaimo l'esempio pratico, tanto per
eliminare tutti i dubbi. Sempre nella Import Table che abbiamo appena esaminato, torniamo all'indirizzo
della IT e troviamo:
6000 B0 61 00 00 - ED 6C 45 37 - FF FF FF FF - 8A 65 00 00 Primo Modulo
F0 63 00 00
18 61 00 00 - B3 C2 1F 37 - FF FF FF FF Secondo Modulo
9C 67 00 00 - 58 63 00 00
- CC 61 00 00 - EB 6C 45 37 Terzo Modulo
FF FF FF FF - 92 6B 00 00 - 0C 64 00 00
- B8 60 00 00 Quarto Modulo
72 C2 3E 35 - FF FF FF FF - F6 6C 00 00 - F8 62 00 00
C0 62 00 00 - ED 6C 45 37 - FF FF FF FF - 7A 6D 00 00 Quinto Modulo
00 65 00 00
- A0 60 00 00 - EB 6C 45 37 - FF FF FF FF Sesto Modulo
DA 6D 00 00 - E0 62 00 00
- 00 00 00 00 - 00 00 00 00 NULL
00 00 00 00 - 00 00 00 00 - 00 00 00 00
bene, così divisi sono più leggibili. Ogni 5 dword abbiamo la struttura IMAGE_IMPORT_DESCRIPTOR, questa
struttura contiene le informazioni sulla dll importata e le sue relative funzioni. Il primo modulo lo
abbiamo già visto, era SHELL32.DLL, ora passiamo al secondo. Andiamo subito alla terza dword, otteniamo
l'indirizzo 0000679C. Andiamo a cercare nel file l'offset e troviamo la stringa KERNEL32.dll, quindi
abbiamo ricavato il nome della dll. Prendiamo la prima dword del secondo modulo e abbiamo il puntatore
00006118, troviamo il seguente array:
EE 66 00 00 - FC 66 00 00
06 67 00 00 - E4 66 00 00 - CC 66 00 00 - 1A 67 00 00
24 67 00 00 - BE 66 00 00 - DA 66 00 00 - 4E 67 00 00
5C 67 00 00 - 6C 67 00 00 - 7E 67 00 00 - 90 67 00 00
B8 65 00 00 - A4 65 00 00 - 96 65 00 00 - 96 66 00 00
B2 66 00 00 - A2 66 00 00 - 66 66 00 00 - 86 66 00 00
7A 66 00 00 - 3C 66 00 00 - 5A 66 00 00 - 48 66 00 00
12 66 00 00 - 30 66 00 00 - 20 66 00 00 - EA 65 00 00
08 66 00 00 - FC 65 00 00 - 30 67 00 00 - DC 65 00 00
CA 65 00 00 - 10 67 00 00 - 40 67 00 00 - 00 00 00 00
questi sono tutti i puntatori a strutture HINT, cioè strutture formate come già visto da una dword che
indica il numero ordinale della funzione e da una stringa. Quindi i puntatori avranno il significato:
000066EE 5F 00 44 65 6C 65 74 65 46 69 6C 65 41 00 _.DeleteFileA
indice ordinale: 5F nome: DeleteFileA
000066FC D1 02 5F 6C 63 72 65 61 74 00 .._lcreat
indice ordinale: 02D1 nome: _lcreat
etc.......
abbiamo i nomi, quindi torniamo nel secondo modulo e andiamo a vedere la quinta dword, 00006358, che ci
dà l'array (IAT):
F5 19 FA BF - AD 07 FA BF
BA 74 F7 BF - D7 07 FA BF - FE 09 FA BF - CC B5 F9 BF
D0 49 F7 BF - B4 48 F7 BF - BB B5 F9 BF - B4 48 F7 BF
D4 71 F7 BF - 07 7D F7 BF - 6F 7F F7 BF - BE 72 F7 BF
AD 77 F7 BF - 16 77 F7 BF - F8 D4 F8 BF - 32 73 F7 BF
2B 08 FA BF - 5F 6E F7 BF - D0 77 F7 BF - 40 7E F7 BF
A9 73 F7 BF - C0 64 F7 BF - 84 72 F7 BF - 57 7B F7 BF
DB 7A F7 BF - 6F 73 F7 BF - 6B 51 F8 BF - C6 20 F8 BF
5F 33 F9 BF - F8 72 F7 BF - 1B 6E F7 BF - 3D 6E F7 BF
DA C5 F8 BF - E4 74 F7 BF - D7 6D F7 BF - 00 00 00 00
e questi sono gli indirizzi veri e propri delle funzioni importate. Non sempre il numero dei nomi di
funzioni è effettivamente uguale al numero degli indirizzi della IAT.
Possiamo quindi riassumere la seguente corrispondenza:
OriginalFirstThunk Nome Funzione FirstThunk
-----------------------------------------------------
000066EE DeleteFileA BFFA19F5
000066FC _lcreat BFFA07AD
etc
ecco quindi spiegato tutto il meccanismo di import. Quando eseguiamo un file, il PE viene caricato in
memoria, poi il PE loader trova nella IT il nome della dll importata, quindi va a vedere gli Original-
FirstThunk, da lì ricava il nome della funzione, e poi va a trovare nella IAT l'indirizzo della funzione
in esame. Prendiamo il caso di DeleteFileA. Disassemblo il notepad.exe e vado a cercare una reference
a DeleteFileA, la trovo alla riga:
004032F7 FF1558634000 call [00406358]
bene, come vediamo il compilatore ha risolto la import con l'indirizzo 00403658. Leviamo l'image base e
ci resta 00006358. Cosa c'è a 6358 nel file? Il FirstThunk di DeleteFileA. Ora l'ultimo passo: andiamo
in sice e settiamo un bel bpx DeleteFileA. Provate ad aprire un file di testo con il notepad, e il sice
popperà nel modulo KERNEL32 all'indirizzo BFFA19E5. Ecco quindi che abbiamo raggiunto il codice della
funzione DeleteFileA.
Visto che anche l'IT è facile ora?
-- Recourse --
Pare che abbiano sbagliato la sintassi sul PEditor: questo è il campo Resource. Nelle risorse troviamo
le stringhe, le bitmap, le finestre, etc. Per il notepad abbiamo l'rva 00007000 ed il size di 51BC.
Non riporto tutti i bytes, ma ci andremo solo ad occupare della struttura directory di questo campo e
vedremo un pò come funzia. A 7000 troviamo la directory:
RESOURCE FLAGS | 00 00 00 00
TIME/DATE STAMP | 11 97 56 01
MAJOR VERSION | MINOR VERSION | 04 00 00 00
# NAME ENTRY | # ID ENTRY | 00 00 07 00
RESOURCE DIR ENTRIES | 03 00 00 00
()- Resource Flags
Non usato, sta sempre a zero.
()- Time/Date Stamp
Dword che contiene data e creazione delle risorse.
()- Major/Minor Version
Due dwords, nel nostro caso Major = 4 Minor = 0. Semplicemente il numero della versione.
()- #Name Entry/ #ID entry
Name entry contiene il numero di oggetti all'inizio dell'array di Directory che hanno i nomi associati.
ID entry contiene il numero di oggetti che hanno delle dwords come nome associato.
Nel nostro caso Name Entry è pari a 0, e ID entry è 7. Detto così non è molto chiaro, spiegheremo tutto
meglio fra poco.
()- Resource Dir Entries
In seguito alla directory c'è un array variabile di elementi che fanno parte della directory entries.
Ora torniamo a Name/ID entry: quelle due words ci dannò il numero di oggetti che hanno o una stringa o
un numero come nome identificatore. Nel nostro caso vediamo che abbiamo sette oggetti che sono
identificabili tramite interi a 32 bit. La struttura di un direcotry entry è fatta nel modo seguente:
NAME RVA/INTEGER ID DWORD
E | DATA ENTRY RVA/SUBDIR RVA DWORD
dove la prima dword è una union tra i campi NAME o INTEGER: può contenere o l'rva che punta al nome
della risorsa (rva a 31 bit però) o un intero a 32 bit che indica l'identificativo della risorsa.
La seconda dword invece è determinata dal primo bit più a sinistra (E):
se E = 0 stiamo considerando i dati di una risorsa
e il seguente campo a 31 bit ci indica l'rva che punta ai dati
se E = 1 stiamo considerando una sottodirectory
e il seguente campo ci indica l'rva del Subdirectory Entry.
bene, ora per capire quello detto facciamo il classico esempio. Prendiamo le risorse del notepad. Queste
cominciano all'indirizzo 7000. Ci andiamo e vediamo i seguenti bytes:
00 00 00 00 - 11 97 56 01 - 04 00 00 00 - 00 00 07 00
questi fanno parte della directory e identificano i campi Resource Flags, TimeDate stamp, major/minor
version, Name/ID entry, e questo lo abbiamo visto. Dopo queste dwords inizia l'array di strutture
Resource Dir Entries (siccome ID entry è sette, prendiamo sette strutture da 2 dwords):
03 00 00 00 - 48 00 00 80 - 04 00 00 00 - 98 00 00 80
05 00 00 00 - B0 00 00 80 - 06 00 00 00 - D0 00 00 80
09 00 00 00 - 00 01 00 80 - 0E 00 00 00 - 20 01 00 80
10 00 00 00 - 40 01 00 80
queste strutture vanno considerate a gruppi di 2 dwords. Vediamone il significato:
00000003 numero identificativo
80000048 subdirectory all'offset 48
--------
00000004 numero identificativo
80000098 subdirectory all'offset 98
--------
00000005 numero identificativo
800000B0 subdirectory all'offset B0
etc
dopo questa struttura troviamo un altra directory:
00 00 00 00 - 11 97 56 01 - 04 00 00 00 - 00 00 08 00
FLAGS TIME/DATE MAJ/MIN ENTRIES
abbiamo 8 entries, quindi prendiamo le successive otto strutture:
01 00 00 00 - 58 01 00 80
02 00 00 00 - 70 01 00 80 - 03 00 00 00 - 88 01 00 80
04 00 00 00 - A0 01 00 80 - 05 00 00 00 - B8 01 00 80
06 00 00 00 - D0 01 00 80 - 07 00 00 00 - E8 01 00 80
08 00 00 00 - 00 02 00 80
anche queste le interpretiamo nel modo precedente:
00000001 numero identificativo
80000158 subdirectory all'offset 158
--------
00000002 numero identificativo
80000170 subdirectory all'offset 170
etc..
e dopo troviamo un altra directory, seguite da altre strutture Resource Dir Entries etc..
ora però abbiamo trovato solo subdirectory, ancora non sappiamo dove sono effettivamente i dati relativi
alle risorse. Abbiamo trovato sempre strutture la cui seconda dword aveva il primo bit attivo (8xxxxxxx)
quindi adesso cerchiamo qualche risorsa vera. La prima la trovo all'offset 7158:
00 00 00 00 - 11 97 56 01 - 04 00 00 00 - 00 00 01 00
ENTRIES
ha una sola entry, quindi prendo la seguente struttura:
10 04 00 00 - 38 03 00 00
NUM ID DATA OFFS
stavolta la seconda dword ha il primo bit a 0 (0xxxxxxxx), quindi vuol dire che i rimanenti 31 bit ci
indicano l'offset dei dati della risorsa: 00000338. Ora questo non è un indirizzo vero e proprio, ma è
un valore da sommare al'rva della Resource(7000): 7000+0338 = 7338. Andiamo a vedere a questo offset:
78 74 00 00 - 28 01 00 00
E4 04 00 00 - 00 00 00 00 - A0 75 00 00 - E8 02 00 00
E4 04 00 00 - 00 00 00 00 - 88 78 00 00 - E8 02 00 00
E4 04 00 00 - 00 00 00 00 - 70 7B 00 00 - 28 01 00 00
E4 04 00 00 - 00 00 00 00 - 98 7C 00 00 - 68 06 00 00
E4 04 00 00 - 00 00 00 00 - 00 83 00 00 - A8 08 00 00
E4 04 00 00 - 00 00 00 00 - A8 8B 00 00 - A8 0E 00 00
E4 04 00 00 - 00 00 00 00 - 50 9A 00 00 - 68 05 00 00
E4 04 00 00 - 00 00 00 00 - B8 9F 00 00 - 06 03 00 00
E4 04 00 00 - 00 00 00 00 - 24 A3 00 00 - CE 00 00 00
E4 04 00 00 - 00 00 00 00 - F4 A3 00 00 - A6 04 00 00
E4 04 00 00 - 00 00 00 00 - 9C A8 00 00 - 64 02 00 00
E4 04 00 00 - 00 00 00 00 - 00 AB 00 00 - 32 0A 00 00
E4 04 00 00 - 00 00 00 00 - 34 B5 00 00 - A8 02 00 00
E4 04 00 00 - 00 00 00 00 - DC B7 00 00 - 38 05 00 00
E4 04 00 00 - 00 00 00 00 - 14 BD 00 00 - 48 00 00 00
E4 04 00 00 - 00 00 00 00 - 5C BD 00 00 - 68 00 00 00
E4 04 00 00 - 00 00 00 00 - C4 BD 00 00 - 22 00 00 00
E4 04 00 00 - 00 00 00 00 - E8 BD 00 00 - 5A 00 00 00
E4 04 00 00 - 00 00 00 00 - 44 BE 00 00 - 78 03 00 00
E4 04 00 00 - 00 00 00 00
queste sono tutte le strutture puntate dalle resource dir entries. Ognuna di queste strutture è formata
da 4 dwords, che hanno il seguente significato:
DATA RVA
SIZE
CODEPAGE
RESERVED
quindi la prima struttura ha i seguenti dati:
00007478 DATA RVA
00000128 SIZE
000004E4 CODEPAGE
00000000 RESERVED
. Data rva
contiene l'rva che punta ai dati veri e propri (finalmente) della risorsa.
. Size
è la grandezza dei dati della risorsa
. CodePage
il valore che dovrebbe essere usato nella decodifica dei code point all'interno del blocco di dati.
. Reserved
riservato! Deve essere 0.
quindi sappiamo finalmente dove sono immagazzinati i dati della prima risorsa. Andiamo all'offset 7478
e troviamo il blocco:
28 00 00 00 10 00 00 00
20 00 00 00 01 00 04 00 00 00 00 00 80 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 80 00 00 80 00 00 00 80 80 00
80 00 00 00 80 00 80 00 80 80 00 00 C0 C0 C0 00
80 80 80 00 00 00 FF 00 00 FF 00 00 00 FF FF 00
FF 00 00 00 FF 00 FF 00 FF FF 00 00 FF FF FF 00
00 00 00 00 00 00 00 00 00 00 07 77 77 77 77 80
00 00 07 77 77 77 77 70 00 00 07 77 77 77 FF 70
00 00 07 77 77 77 77 70 00 00 00 00 00 77 77 70
6E EE EE EE E6 07 7F 70 0E EE EE EE EE 07 77 70
06 EE EE EE EE 60 77 70 00 EE EE EE EE E0 77 70
00 6E EE EE EE E6 07 70 00 0E E6 66 66 EE 07 70
00 06 E6 66 66 6E 60 70 00 00 EE EE EE EE E0 70
00 00 08 66 86 68 60 00 00 00 00 00 00 00 00 00
F8 01 00 00 F0 00 00 00 F0 00 00 00 F0 00 00 00
F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 00 00 80 00 00 00 C0 00 00 00 C0 00 00 00
E0 00 00 00 E0 00 00 00 F0 01 00 00 F8 03 00 00
28 00 00 00 20 00 00 00
Questo corrisponde al disegnino dell'icona del notepad. Basta cambiare questi bytes per cambiare l'icona
del notepad (vedremo fra un pò il visualizzatore di risorse). Si procede allo stesso modo per tutte le
altre risorse.
-- Exception -- & -- Security --
Questi due campi sono sconosciuti, non ho trovato nessuna documentazione.
-- Basereloce --
Sta per base relocation. Abbiamo già parlato delle rilocazioni, abbiamo detto che le variabili statiche,
le stringhe etc venivano caricate ad un diverso indirizzo da quello specificato in ImageBase. Il campo
basereloc ci dà un puntatore (alla sezione .reloc) alla struttura che contiene le informazioni per
effettuare la rilocaione. Nel caso del notepad abbiamo un D000 e un size di 93C. Al solito andiamo a
vedere con i nostri occhi la Relocation Table (anche chiamata Fixup Table):
00 10 00 00 - 68 02 00 00 - D5 30 1B 31 - 36 31 45 31
52 31 5A 31 - 61 31 67 31 - 6F 31 76 31 - 7D 31 81 31
8A 31 A2 31 - AF 31 BD 31 - C2 31 CC 31 - D1 31 D9 31
E7 31 EC 31 - F6 31 FB 31 - 06 32 0F 32 - 23 32 29 32
3D 32 74 32 - 7B 32 B9 32 - C3 32 C8 32 - DC 32 E6 32 continua....
ho riportato solo un pezzo, tanto basta e avanza. Al solito vediamo la struttura teorica di questa roba:
PAGE RVA
BLOCK SIZE
TYPE/OFFSET | TYPE/OFFSET
TYPE/OFFSET | continua...
la prima dword (page rva) è 00001000, ed ci dà l'rva che serve per individuare dove andare ad effettuare
la rilocazione, poi BlockSize indica il numero di bytes del blocco da rilocare. Tutte le word successive
sono TYPE/OFFSET formate nel modo:
bit 15---11---------0
Type Offset
in cui Type indica il tipo di rilocazione a seconda del suo valore:
. 0 = Assoluta
E' un nop. La rilocazione viene saltata.
. 1 = High
L'offset punta alla parte alta (16 bit a sinistra) di un indirizzo a 32 bit, in questa parte alta
vanno applicati i 16 bit di rilocazione.
. 2 = Low
Come prima, l'offset punta alla parte bassa (16 bit a destra) di un indirizzo a 32 bit, ed è lì che va
applicata la rilocazione.
. 3 = HighLow
L'intera relocazione a 32 bit va applicata all'intero indirizzo a 32 bit.
. 4 = HighAdjust
Si tratta sempre di una rilocazione a 32 bit, ma con dei calcoli in più (che sono incomprensibili).
. 5 = MipsJmpAddr
sconosciuto
. 6 = Section
sconosciuto
. 7 = Rel32
sconosciuto
tornando all'esempio pratico, nella nostra Relocation Table avevamo le seguenti info:
00 10 00 00 - 68 02 00 00 - D5 30 1B 31 - 36 31 45 31 etc...
cioè la rilocazione inizierà all'rva 00001000 e sarà lunga 0268h byte. La lunghezza però comprende anche
le 2 dword iniziali, quindi per sapere quante rilocazioni occorreranno dobbiamo sottrarre 8 bytes a size
(gli 8 bytes delle prime 2 dwords), 268h - 8 = 260h, e ora dividiamo per 2 il numero di bytes (così
otteniamo le words delle reloc), 260h / 2 = 130h = 304 (dec) rilocazioni.
-- Debug --
Anche questo campo ci dà l'rva di una struttura. Questa contiene info per il debugging, la descriverò
fra poco.
-- Copyright -- & -- Globalptr --
Sconosciuti
-- Tls Table --
Ci dà l'indirizzo del Thread Local Storage. Ne parleremo fra poco.
-- Load Config --
sconosciuto
-- Bound Import --
Questo per rispondere a WebCide che mi ha fracassato di domande l'altro giorno in chat :-P. Abbiamo già
visto gli OriginalFirstThunk e i FirstThunk. Quando il PE loader carica un eseguibile, trova le imports,
carica in OriginalFirstThunk gli rva del file ai nomi di funzioni, al tempo stesso li carica anche nella
struttura dei FirstThunk. Poi carica le dll varie, ottiene gli entry point delle funzioni da importare
e le va a sostituire ai valori dei FirstThunk. Ora, nella maggior parte dei casi l'entry point di una
funzione in una dll sarà sempre lo stesso, quindi possiamo mettere nei FirstThunk direttamente gli entry
point, in modo che il loader non perda tempo a metterceli per noi. Questo processo si chiama "binding".
Ovviamente se abbiamo i FirstThunk già settati sugli Entry point delle funzioni, ma per un qualsiasi
motivo a quegli indirizzi non vengono trovate le funzioni, il loader se ne accorge (o dal numero di
versione della dll, o da una avvenuta relocazione) e quindi ecco che ritorna agli OriginalFirstThunk per
andarsi a ricalcolare l'entry point giusto delle funzioni considerate.
-- Import Address Table --
Abbiamo già trattato la IAT nella sezione della IT, cmq questo valore è superfluo, in quanto già
specificato nella directory entry dell'IT. Indica il puntatore rva all'inizio della IAT.
Okkey, adesso rimangono solo i pulsantini del gruppo view:
Exports, Imports, Resource, Debug, TLS.
Ognuno di essi apre una finestra a parte, e servono solo a visualizzare in una interfaccia utente i dati
delle export table, import table, risorse etc.
** EXPORTS **
Prendo la solita wz32.dll e guardo le imports. Sulla sinistra sono riportati tutti i valori della
struttura che già abbiamo commentato, nella destra avete le funzioni ordinate per indice, con i relativi
rva e nome.
** IMPORTS **
Nel riquadro superiore avete i nomi dei moduli importati (i file dll), cliccate su un modulo e nel
riquadro inferiore appariranno le funzioni importate da quel modulo, complete di rva, offset, hint e
nome (che già abbiamo descritto in dettaglio).
Il riquadro superiore merita un attimino di attenzione: nella descrizione dei moduli compaiono le voci
corrispondendi a FirstThunk, OriginalFirstThunk etc. che ho già descritto.
** RESOURCES **
Beh, avete il visualizzatore ad albero delle risorse, avete anche il visualizzatore delle icone! Mitico!
A destra avete le info sui valori che ho già discusso prima (name entries, etc..), e per ogni risorsa
avete in basso a destra la locazione (rva) e il suo size. La prima risorsa è un icona, ed è la classica
icona del notepad (come già visto prima; se osservate attentamente il blocco ascii relativo all'icona,
vi sembrerà di intravedere il disegnino del notepad! infatti è così).
** DEBUG **
Per vedere qualcosa in questo campo dovete creare e compilare un eseguibile con le info di debug (il
visual c++ lo fa in automatico). Debug quindi vi aprirà un dialog con le informazioni delle strutture di
debug. Una struttura di debug è formata nel seguente modo:
CHARACTERISTICS
TIME/DATE STAMP
MAJOR VERSION | MINOR VERSION
DEBUG TYPE
DATA SIZE
DATA RVA
DATA SEEK
dove: Characteristics è sempre a zero,
TimeDate Stamp è la data e ora della creazione delle info di debug
Maj/Min Version è la versione delle info di debug
Debug Type è il formato delle info di debug, che può essere in simboli COFF, FPO, o CodeView
Data size è il numero di bytes dei dati di debug (escluse le debug directory)
Data rva è appunto l'rva dei dati di debug
Data seek è il seek value dall'inizio del file fino ai dati di debug
Il campo Debug (nella Directory) ci indica l'rva dell'array di queste strutture di debug. Il debug
viewer semplicemente ci permette di scorrere una ad una tutte queste strutture. Francamente non sembra
funzionare molto bene.
** TLS **
Acronimo di Thread Local Storage. Questa struttura non la descriverò, anche perchè il suo funzionamento
non mi è ancora molto chiaro, e ciò è dovuto al fatto che non riesco a trovare un eseguibile che abbia
una TLS. La TLS contiene dei dati che verranno usati dai thread. In particolare la struttura contiene
anche un array di rva dei Callback, cioè un array di funzioni che devono essere richiamate prima e dopo
la creazione del thread.
-------------------------------------------------------------------------------------------------------+
-o NOTE |
-------------------------------------------------------------------------------------------------------+
Nella descrizione della IT ho usato il modello classico, che è quello della struttura:
Image_Import_Descriptor Struct
union
characteristics dd? (Import Flags)
OriginalFirstThunk dd ?
ends
TimeDateStamp dd ?
ForwarderChain dd ?
Name1 dd ?
FirstThunk dd ?
Image_Import_Descriptor Ends
però nella documentazione del pe.txt rilasciata da Microschif troviamo per l'IT la seguente struttura:
IMPORT FLAGS
TIME/DATE STAMP
MAJOR VERSION | MINOR VERSION
NAME RVA
IMPORT LOOKUP TABLE RVA
IMPORT ADDRESS TABLE RVA
la differenza è data dal fatto che alcuni compilatori usano la seconda struttura per costruire la IT.
Con questa struttura non avete gli OriginalFirstThunk, e dovete risalire al nome delle funzioni usando
i FirstThunk. Poi l'array di FirstThunk viene sovrascritto con gli entry point delle funzioni importate.
E' chiaro che in questo caso non potete avere le bound import. Di solito possiamo capire quale struttura
ci troviamo di fronte semplicemente dalla prima dword: se la struttura rientra nel primo caso, allora la
prima dword conterrà l'rva per i nomi delle funzioni, se la struttura rientra nel secondo caso allora la
prima dword sarà settata a zero. Praticamente è proprio questa union che determina il tipo di struttra
della IT.
Quando ho parlato del Rebuilder ho detto che potreste ritrovarvi ad aver ricostruito la IT di un prog,
però scoprirete che tale prog funziona solo sul vostro pc. Il problema è legato ai Thunks. Infatti nei
FirstThunk troviamo o gli indirizzi degli entry point delle funzioni importate, oppure troviamo una
copia degli OriginalFirstThunk. In tal caso il loader pensa ad ottenere gli entry point delle funzioni e
a sovrascriverle alla copia degli OriginalFirstThunk per ottenere i veri FirstThunk. Se voi dumperete la
IT dopo questo processo, vi ritroverete una IT che non è l'originale, ma il file funziona in quanto ha
già prepatchati gli entry point delle funzioni. Può capitare che non tutte le dll carichino il loro
codice sempre allo stesso indirizzo (per vari motivi). Nello stesso pc al 99% delle volte gli indirizzi
sono sempre quelli, ecco perchè sul vostro pc funziona, però su un altro pc gli indirizzi probabilmente
saranno diversi, e quindi il file non funzionerà. Voi direte: ma abbiamo sempre gli OriginalFirstThunks,
si ma questo se il file usa la prima struttura della IT. Se usa la seconda descritta poc'anzi, allora
non avremo gli OriginalFirstThunk e i FirstThunk sono sbagliati. Per risolvere il problema dovrete
quindi dumpare la vostra IT prima che venga sovrascritta con i FirstThunk.
-------------------------------------------------------------------------------------------------------+
-o LIBRARY, THANKS, LINKS AND E-MAIL |
-------------------------------------------------------------------------------------------------------+
Per documentarvi meglio sul formato PE vi consiglio l'utilissimo documento PE.TXT che trovate un pò
dovunque (quello rilasciato da Microzozz Developers Support) e anche la documentazione di LuevelsMeyer.
Inoltre vi consiglio i tutorial sul PE che trovate sul RingZero, e vari tutorial sul Manual
Unpacking che trovate alla UIC. Vi consiglio anche i testi di Iczelion e tanti altri buoni testi che
adesso non mi vengono in mente, ma ce ne sono molti. Studiate, studiate!
Saluto tutta la UIC, il RingZero e gli Spippolatori, un salutone a Yado che col suo Krypton ci costringe
a studiare molto sul packing! Non dimentichiamo poi gli HackManiaci che mi hanno co
involto nello scrivere
questo documento. And last but not least un salutone a Syscalo e Ritz che hanno supervisionato questo
testo (e che si sono incazzati perchè non li avevo salutati :-P)
E poi non poteva mancare il saluto al Quaqquaro!!! Ma io e te non dovevamo fare a botte? hihihihihi :-P
Some linkz:
www.ringzero - il ringzero! Grazie di esistere!
www.hackmani - bravi guaglioni
www.uic-spippolatori.com - la UIC (università italiana crackers)
www.spippolatolri.com - gli spippolatori
...and MY stuff:
www.andreageddon.8m.com - il mio sito
andreageddon@hotmail.com - la mia email
irc.azzurra.it -> #crack-it #hackmaniaci - canali bazzicati su irc.
- EOF - (pant pant!)
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [MISC] #00 - 18/12/2000 |
| Introduzione ai MUD [Mysha] 0x08/0x0E |
+-------------------------------------------------------------------------------+
Innanzitutto benvenuti a tutti, spero vivamente che gli articoli che scrivero' saranno utili a molti di voi.
Sono qui pronta a rispondere alle vostre 1000 domande di qualsiasi tipo.
Ricordo inoltre che non intendo ritenermi responsabile di qualsiasi azione tenterete di fare leggendo queste mie scritture e applicandole.
Baci Baci.
Mysha
***************************************
MUD & MO*
La differenza fra Mud e Mo* e' basilare e di concetto abbastanza semplice.
Tutti permettono l'uso di un client Telnet per collegarsi ad un server e permetterci di entrare in un mondo virtuale di solo testo per giocare o per dialogare e conoscresi.
Ecco i tipi di Multi User (mu*) che esistono:
M.U.D. e' l'acronimo di Multi User Dungeon, anche se ultimamente, per renderla piu' generale e comprensiva di ambientazioni diverse da quella Fantasy si tende a decodificarla in Multi User Dimension.
M.U.S.H. Multi User Shared Allucination, che si rifa' al concetto, tipico e topico della sottocultura Cyberpunk, della Rete come Allucinazione Condivisa da Molti Utenti (la "MatriX" di Gibson e Sterling)
M.O.O. che hanno una struttura Object Oriented (OOP, appunto) e offrono possibilita', legate alla struttura del codice, ben diverse dagli altri citati, ma sono in genere piu' orientati al "sociale" che al "gioco di ruolo".
Quindi la differenza sta nel fatto che i Mo* in generale ci permettono di entrare in questo "mondo" con il solo scopo di conoscere nuove persone camminando per stanze, foreste, laghi e altri luoghi. Possiamo identificarli in maniera molto profana come delle Chat particolari.
I Mud invece si contraddistinguono per la loro possibilita' di giocare su internet in questi "mondi".
Il Mud non e' nientaltro che un programma, scritto principalmente in C++ o perl, che risiede su un server e, esegue comandi che noi digitamo portandoci a compiere azioni di vario genere.
I Mud ci permettono principalmente di fare Gicochi di Ruolo ambientati in mondi Fantasy, futuristici o di inventiva del programmatore.
Il divertimento maggiore dei Mud e' che saremo a contatto con molte persone che come noi saranno collegate ad un server e, interagendo con loro, avremo la possibilita' di avventurarci a ammazzare draghi, immedesimarci in combattimenti corpo a corpo e intraprendere missioni in vero stile avventuriero senza che nessuna storia sia gia' scritta (la storia la creiamo noi compiendo le azioni che vogliamo!).
Quando ci collegheremo ad un Mud (piu' avanti avrete delle liste di Mud con relativi link e descrizioni) dovremo creare il nostro personaggio (chiamto comunemente PG), sceglierne una razza (umano, elfo, nano, orco, ecc ecc) e deciderne una classe (guerriero, mago, ladro, ranger, ecc ecc).
Ogni razza avra' caratteristiche diverse e, ci permettera' di avere diverse agevolazioni su un lato e difetti su un altro.
La classe invece identifica cio' che faremo su un Mud, e ci servira' per avere delle abilita' specifiche del caso.
Purtroppo la maggior parte dei mud si basa a livelli e cioe', ammazzando mostri avremo dei punti (chiamati XP) che ci serviranno per aumentare di livello (chi conosce i giochi di ruolo posso semplificare dicendo: un avanzamento alla Dungeon & Dragon) e quindi portando il gioco di ruolo a bassi livelli; sara' piu' una corsa ad ammazzare per primo i mostri per diventare di altissimo livello e quindi invincibili.
L'unico MUD italiano conosciuto sino ad oggi che ci permette di vivere vere avventure e di fare del vero gioco di ruolo e' "The Gate", dove il sistema non si basa su livelli, ma bensi' su un'interpretazione che noi daremo al nostro PG.
In "The Gate" avremo la possibilita' di intraprendere cariere di lavoro come il minatore, il falegname, il boscaiolo e altro ancora.
Questo Mud e' dedicato ai veri amanti del GdR (giochi di ruolo).
Cio' che ora ci serve e' capire come collegarci ad un Mud.
Per collegarci basta il semplice programma dato in dotazione di Windows chiamato Telnet (di norma risiede nella directori di installazione di windows e si chiama "Telnet.exe").
Dovremo configurarlo mettendo come nome Host il nome del server dove risiede il Mud al quale giochiamo e la porta ad esso dedicato.
Purtroppo il programma Telnet ha molte limitazioni e quindi consiglio vivamente di scaricarsi il programma ZMud (www.zmud.com) (per The Gate scaricate il suo client che si trova sul suo sito "thegate.ngi.it" che e' molto meglio...ma solo per The Gate!), che non e' nientaltro che un Telnet avanzato per i mud e che ci permette di programmare trigger, alias e altro ancora (ne spiegheremo la funzionalita' nel capitolo dedicato).
In questa prima puntata non entreremo ad analizzare Mud per Mud, ma a darne una descrizione generale di alcuni di essi.
Nella prossima sezione parleremo piu' specificatemente a livelli tecnici come funziona un Mud e ci soffermeremo su ogni Mud per carpirne i segreti.
Nome: Anacronia
Nascita: marzo 2000
Amministratori: Ilithiiri, Sarkan
Indirizzo: anacronia.luda.it Porta 9000
Sito Web: anacronia.luda.it
Recensione:
- 12 classi e 18 razze;
- 18 religioni;
- 103 aree;
- 100 livelli (90 da mortali, gli ultimi 10 da immortali);
- Possibilita' dei personaggi di indossare ogni genere di oggetto, per esempio spade antiche a spade laser.
Nome: Atlantis
Nascita: giugno 2000
Amministratori: Aragorn, Eldharion, Jastar, Nather, Solyan
Indirizzo: atlantis.lanandgames.it Porta 4000
Sito Web: atlantis.lanandgames.it
Nome: Clessidra
Nascita: ? 1996
Amministratori: Aerk, Joker, Magnus
Indirizzo: clessidra.anvi.it Porta 4000
Sito Web: www.clessidra.anvi.it
Recensione: MUD completamente in italiano con comandi in italiano o in inglese, a seconda delle preferenze dell'utente;
- Alcune aree sono PKILL;
- 18 razze e 20 classi;
- Tutte le aree sono originali (non tradotte), unite da una wilderness di 130x130 locazioni (in corso di espansione);
- I maestri non sono divisi per classi ma per abilita'.
Nome: Dalila 2
Nascita: gennaio 1998 (1)
Amministratori: Shade, Fizban, Offar, Ferus, Chardhros, Jerold, Khud, Sophya, Aphrael, Ilweran
Indirizzo: dalila2.shopitaly.net Porta 4000
Sito Web: dalila.shopitaly.net
Nome: Lands of Darkness
Nascita: aprile 2000
Amministratori: AryHann, Chastil, Mobius, Tricksty
Indirizzo: mud.landsofdarkness.it Porta 4000
Sito Web: -
Recensione:17 razze, tra cui tutte le varieta' di giganti e altre originali;
Oltre alle classi standard anche il difficilissimo Samurai e il misterioso Vampiro;
Possibilita' di fare le quest grazie al mob QUESTOR, che paga direttamente i sigilli e li converte in premi;
107 aree che verranno presto interamente tradotte in italiano;
Sistema di aste;
Possibilita' di aumentare le proprie caratteristiche;
Numerose abilita' e magie;
Possibilita' di scegliere una religione in base al proprio allineamento o alle proprie aspirazioni;
Con la morte (escluso il samurai che puo' morire al massimo 10 volte) si perdono solo punti costituzione, che grazie ai "train" possono essere prontamente recuperati;
Possibilita' di PKilling;
Arena;
Sistema di backup di personaggi
Nome: Lumen et Umbra
Nascita: ? 1994
Amministratori: Benem, Joy
Indirizzo: mclmud.mclink.it Porta 6000
Sito Web: leu.cjb.net
Recensione:Il primo Mud Italiano con la traduzione delle locazioni. Ben fatto e ben implementato su tuti i fronti.
Essendo stato il primo MUD italiano ha una grande stabilita' e una grande varieta' di classi.
Comandi in inglese ma intuibili e disponibile un HelpMud che descrive tutti i comandi.
E' stato i mio primo MUD:)
Nome: Nebbie Arcane
Nascita: agosto 1997
Amministratori: Alar, Darkstar, Xanathon
Indirizzo: nebbie.nebbie.it Porta 4000
Sito Web: www.nebbie.it
Nome: Silmaril
Nascita: ? 1996
Amministratori: Diego P., Nicola F., Paolo P., Rossano C.
Indirizzo: silmaril.novacomp.it Porta 4000
Sito Web: silmaril.freeweb.org
Nome: Tempora Sanguinis 2
Nascita: luglio 1996 (1)
Amministratori: Dryden, Gabriel, Logan, Sybil
Indirizzo: ts.roxybar.it Porta 4000
Sito Web: www.ts.roxybar.it
La lista che segue sono ancora MUD in fase di Testing ma e' possibile giocarci per aiutare gli amministratori a implementare nuove funzioni:
Nome: Breed of Darkness
Nascita o fase: in beta
Amministratori: Razor, Ender, Dheadlon, Chinook
Indirizzo: darkmud.gamersrevolt.com Porta 4000
Sito Web: -
Nome: Dragon Storm
Nascita o fase: alpha test
Amministratori: Nihil, Shatar, Azrael, Hastur, Atma
Indirizzo: ds.gioco.net Porta 9000
Sito Web: ds.gioco.net
Nome: Holy & Secular
Nascita o fase: sett. 2000
Amministratori: Ade, Nikodemus, Draykos
Indirizzo: www.cec.it Porta 5000
Sito Web: -
Nome: Lost in Nowhere
Nascita o fase: in beta
Amministratori: Asmodeus, Blink, Eris, Irina, Marte, Myst, Tulkas
Indirizzo: priscilla.fattorek.com Porta 4000
Sito Web: priscilla.fattorek.com/mud
Nome: Revolution
Nascita o fase: alpha test
Amministratori: Richard Greenwood, Macs
Indirizzo: rev.gamersrevolt.com Porta 4000
Sito Web: -
Nome: The Gate
Nascita o fase: giugno 2000
Amministratori: Tempus, Avenger, Elavar, Destino
Indirizzo: thegate.ngi.it Porta 7890
Sito Web: thegate.ngi.it
Newsgroup: thegate.ngi.it Porta 119
Recensione: FANTASTICO!!! Suppongo che questa parola basti per descrivere il MUD del Gioco di Ruolo per eccellenza.
Non si basa su classi definite, ma besni' ogni giocatore ha la possibilita' di intraprendere la cariera che vuole e cambiandola in ogni momento.
In piu' il client grafico scaricabile GRATUITAMENTE dal sito Web ci permette di avere un mappa grafica e altri elementi non disponibili da nessun'altro MUD.
Consiglio caldamente a tutti gli amanti del GdR di provarlo anche perche' la fase di testing sta per essere conclusa.
Baci Baci.
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [MISC] #00 - 18/12/2000 |
| ZMUD E LE SUE POTENZIALITA' (TRUCCHETTI E ALTRO) [Mysha] 0x09/0x0E |
+-------------------------------------------------------------------------------+
Premetto che per capirci qualcosa da questo articolo dovreste gia' conoscere i comandi di uno specifico MUD e aver almeno letto il capitolo MUD & MO*.
PREMETTO INOLTRE CHE QUANTO SPIEGO SOTTO E' STATO PROVATO (e funzionante) DA ME STESSA IN LUMEN ET UMBRA.
I client per giocare ai MUD sono svariati e ognuno con funzionalita' simili e dissimili.
Ci sono molti client gratuiti quali Portal, Smm+, WinMud ecc ecc,e molti di loro sono gratuiti, ma Zmud ha veramente una marcia in piu' per le personalizzazioni che ci permette di fare e per la semplicita' nel configurarle.
Zmud lo troverete in versione Shareware al sito www.zmud.com ma facilmente registrabile scaricando un crack al sito www.astalavista.box.sk.
Una volta collegati al server del nostro MUD, abbiamo la possibilita' di programmare trigger, alias e tutto cio' che ci serve.
Un ALIAS ci permette di sostituire un comando composto digitando una sola parola.
Cliccando sull'icona ALIAS che compare nella parte alta dello schermo, avremo la possibilita' di inserire il comando da eseguire nella riga 'command:' e il nome dell'alias in 'alias name:'.
Poniamo un esempio:
se devo lanciare un incantesimo contro un mob che si chiama Ade, scrivedno il comando normalmente dovremo scrivere (mi riferisco al mud Lumen et Umbra): "cast 'acid blast' Ade".
Capite che se devo lanciare 2 incantesimi di fila e fare altre azioni lo scrivere tutto questo mi portera' a perdere molto tempo e rischiare di morire.
Programmando l'alias noi metteremo come nome "Acid" e come comando "cast 'acid blast' ".
Se ora noi scriveremo "Acid Ade" nella riga dei comandi, automaticamente avremo un Acid blast su Ade:)
Ora programmeremo un alias per raccogliere la spada per ogni volta che il nostro avversario ci disarma e ci cadra' a terra l'arma.
Alias name: "spada" Command:"get spada;wield spada"
il punto e virgola permette di dare comandi multipli.
Per ogni volta che noi digiteremo "spada", lo ZMUd in automatico raccogliera' la spada da terra e la impugneremo.
Bene, fino ad ora molto carino il tutto...ma come possiamo usare piu' a fondo ZMUD?
Semplice, combinando gli alias ai trigger.
I trigger sono comandi automatici che ZMUD mandera' al server se ricevera' una determinata riga di testo.
Cioe' per ogni volta che il server mi scrive: "Ci sono dei soldi a terra", il trigger automaticamente riconoscera' la frase e compira' un comando da noi programmato.
Per programmare un trigger bastera' mettere la frase che ZMUD deve identificare e il comando che dovra' eseguire.
Cosa possiamo fare combinando alias e trigger?
Risposta molto semplice....diventare forti al massimo livello senza mai toccare la tastiera:)
Come?
Allora poniamo il caso di programmare una macro con un percorso da fare.
e il trigger che mi riconosce quando arrivo in una determinata locazione, poi il trigger che se vede il mob (mostro) lo attacca in automatico, ora partono i trigger che comabttono, quando un mostro e' morto programmo il trigger per tornare a casa e mangiare, poi se uccido un mob e posso livellare (cioe' passare di livello) richiamo l'alias per andare alla mia Gilda e livellare...ecc ecc...
Io ho provato e, sono diventata livello 45 in 3 giorni di gioco senza MAI toccare la tastiera:)
In base anche al livello che ero facevo scegliere in automatico il MOB da attaccare per avere mostri sempre piu' forti:)
Ammetto che ho perso circa 2 giorni a programmarle, ma poi ditemi una sola persona che diventa 45° livello in soli 3 giorni:)
L'unica cosa che ho lasciato il PC collegato a internet per 3 giorni consecutivi senza MAI staccarlo (72 ore di connessione circa difilate:) ma con un abbonamento FLAT risolverete anche questo problema di costi telefonici:)
Sicuramente saro' criticata per i trucchetti che ho comunicato, ma questo non mi interessa:) non ho ancora finito di fornire trucchetti per i MUD:)))))
Sicuramente un grosso problema e' che in un MUD ci si stanca e, usando un solo PG, si rischia di morire molto spesso (quindi programmate i trigger in modo che i mostri che ucciderete non saranno difficili da fare, tanto anche se ci si mette qualche ora in piu' a chi gliene importa?va in automatico!:))))
Ma esiste anche un secondo metodo che trattero' nella prissima puntata.
Come usae vari PG insieme avendo IP diversi (quindi accettati da tutti i server che vietano il Multiplayng:))
Baci Baci.
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [MISC] #00 - 18/12/2000 |
| Cronache dallo SMAU [Tdi110cv] 0x0A/0x0E |
+-------------------------------------------------------------------------------+
#######################################
# ++++++++++++++++++++++++++++++ #
# + Un incontro in quel di Milan + #
# ++++++++++++++++++++++++++++++ #
#######################################
Autore : TDI110CV
Luogo : Ufficio
Orario : 13.30 (pausa !!!)
e-mail : tdi110cv@iname.com
Telefono : +8888 - 88
Bene , e' passato anche lo SMAU , e con lo SMAU anche il nostro incontro !
Che dire !?
Abbiamo passato due giorni insieme , due giorni in cui ci siamo anche
conosciuti un pochino !
Completamente diversi gli uni dagli altri , abbiamo saputo ridere scherzare
e valorizzare le nostre attitudini e se vogliamo anche le nostre conoscenze !
Ovviamente molti mancavano all'appello ma cio' che conta e' : "meglio pochi
pochi ma buoni"
Ricordo con molto piacere la , come potrei definirla , strepitosa , nonchè
signorile , e anche un po' Barocca , stalla dove il vecchio JEY ci ha fatto
pernottare !
Si direi proprio una STALLA!Ma quale stalla , stalla e' quasi un complimento !
Pero' , se vogliamo guardare anche i lati positivi ... (quali ?) , ehmmmm
si dai forse il prezzo !
E' andato un 50 a testa in centro a Milano ! Pensate un po' voi !
Pero' avevamo il riscaldamento ! Si due buoi ai lati del letto !
Vabbè tralasciando la miseria in questione , c'è da dire che lo SMAU lo
lo abbiamo visto ... con il binocolo !
Un tale WEBBY (chi cazzo e' questo ?) , ci costrinse a girare e rigirare tutta
la fiera per circa 35 volte , senza mai darci la possibilita' di vedere
qualche cazzo di cosa !
Cmq l'importante e' aver visionato in lungo e in largo il padiglione piu'
importante della fiera ! Si quello di MICROSHITT ! All'interno del quale il
buon JEY ha saputo rallegrare l'ambiente emanando un sottile profumo di ...
... ehmmm ... si dai chiamiamolo incenso ! Al termine del quale tutti
i bambinetti che erano intenti all'apprendimento delle novita' di casa
MICROSHAFT e a guradare il culo alle STENDISTE , ne uscirono barcollanti !
Non si capisce pero' se gli effetti negativi su quei fisici minorati , ehmmm
scusate volevo dire minuti , furono causati da un eccessivo uso ed abuso di
winmerda oppure da cio' che jey emanava nell'aria !
Al di la di tutte queste cazzate , posso dire che abbiamo trascorso due giorni
molto tranquilli e sereni !
Ricordo anche in particolar modo il piccolo deficiente intento davanti al suo
videoproiettore a sottolineare la stabilita' , la sicurezza , e la velocita'
di windows !
E direi che condivito in pieno le sue convinzioni ! Si certo !
Per fare un semplice esempio il netbios , parte perennemente integrante al O.S.
in oggetto , ha una velocita' di trasmissione dei dati veramente notevole !
Non crasha mai , se vuoi metterlo in crisi lo devi eliminare :PPP , ed e'
sicurissimo ! Si e' sicuro che se hai una condivisione attiva ti ritrovi
un palo nel culo !
Pero' mettendo da parte queste piccolezze , volevo sottolineare la classe di
WEIS ! Si certo ! Si e' bekkato un alberghetto niente male (250.000 a notte)
per pernottarci con la consorte !
Infame !!! Ci hai tradito ! Tu con la consorte , e noi in tre nella stessa
stanza !!! (gli altri sono andati a casa )
Porca la mignotta mi son trovato nel letto matrimoniale con il MALKA , il
quale durante il tentativo di hackeraggio del mio fondoschiena si e' trovato
la sorpresina !!!
Io sono un tipo previdente ! Ho attivato il "CONSEAL PARACUL FIREWALL Ver. 69"
dichiarato dal Presidente degli Anonimi GAY ITALIANI non hackerabile !
E poi chi altri ? An si c'era anche Sensos un uomo un preservativo !
(dichiarato fornitore ufficiale !!!)
Il TRIT , che dire del TRIT ? Se vi dico "centro sociale" che cosa puo'
venirvi in mente ?
Ebbene non puo' altro che venirvi in mente lui ! Il classico personaggio da
cantina , portatile , e via che si fotte il mondo ! Lui si che e' una gran
persona !
Inoltre ... e tenetevi forte , eccolo lui il piu' invidiato colui che con
la finanza ha rapporti estremamente profondi , l'insostituibile , il piu'
smanettone ... LORD_AXEL !!!!!
Un personaggio che definirei ... un personaggio !!! Sportivo , guzman ,
un figarolo , un ... tirapacchi !!!! Tirapacchi ? e' si si si !
Allo smau ti sei fatto vedere per 15 minuti in tutto ! :(((
Vabbè perdonato ! Ti posso capire eri con la ... morosa :PPPP
E poi il CER , il piu' piccolino , il quale prima ancora di salutarmi mi prese
in contropiede con una serie di trecentomila domande sugli exploit piu'
recenti e solo in fine mi disse :'Ciao TDI come stai ?'
E vabbè che cosa ci si puo' fare ?
Noi HM abbiamo solo lo scopo di insegnare , divertirsi e divertire !
E se non ce la si fa con persone del genere ... dite un po' voi !
Alla Proxy ... il Vostro TDI110CV !!!
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [L'APPRENDISTA STREGONE] #00 - 18/12/2000 |
| CODING 4 DUMMiEZ: EXCEL... APPARENTEMENTE UN'APPLICAZIONE [Mysha] 0x0B/0x0E |
+-------------------------------------------------------------------------------+
Devo premettere che cio' che leggerete sara' dedicato a Excel 97 e superiori per problemi di incompatibilita' di linguaggio Visul Basic delle precedenti versioni.
Excel penso che sia uno dei migliori programmi di Microsoft (forse l'unico) che ha una grande duttilita' per fare cio che vogliamo.
Nel corso che seguira' a questa breve introduzione spiegeremo come programmare al meglio Excel permettendoci di fare cio' che vogliamo.
Excel, oltre all'interfaccia intuitiva per creare tabbelle e grafici offre la possibilita' di creare programmi in Visual Basic al suo interno e, a differenza di Word, e' piu' semplice da aprrendere per chiunque non sappia cosa sia un linguaggio di programmazione.
Aprendo un nuovo foglio in Excel e andando al Menu' Strumenti avremo la voce macro che conterra' "Editor di Visual Basic".
Aprendolo vediamo che appare una nuova finestra con a sinistra il nome del nuovo file e i nomi dei vari fogli.
Nel menu' dell'editor in alto avremo il menu' "Inserisci" che sara' quello che serve a noi per programmare.
Il linguaggio usato e' una versione di Visul Basic un po' particolare ed alleggerita che pero' ci permettera' di fare cio' che vogliamo.
Introducendo il discorso potremmo dire che le macro sono un insieme di istruzioni che verranno eseguite per svolgere determinate funzioni in automatico.
Avendo visual basic avremo la possibilita' di creare piccoli virus (o anche grandi virus se avete dimestichezza del linguaggio:)) o di esaminare i file di una rete senza permissione e tanto altro:)
Concludendo direi che da un applicativo semplice, riusciamo a ricavare qualcosa di veramente intelligente e molto utile.
Baci Baci.
***************************************************
PROGRAMMAZIONE: EXCEL -PARTE 1 (PER INESPERTI)-
Innanzitutto vi consiglio di leggere "EXCEL ... APPARENTEMENTE UN APPLICAZIOE." se siete veramente a conoscenza zero per quanto riguarda la programmazione di macro in Excel.
Questo corso si articolera' di volta in volta sino ad arrivare alle funzioni piu' complesse del linguaggio.
I comandi verranno spiegati in maniera molto sintetica quindi vi consiglio di guardare la guida in linea di excel che e' molto esauriente al merito.
In questo corso si analizzera' maggiormente la struttura di programmazione e le combinazioni di istruzione che ci porteranno al nostro fine prestabilito.
Per provare i programmi che vi spiego potete semplicemente aprire un nuovo foglio e copiare e incollare la struttura nel modulo (poi capirete meglio) per eseguirlo.
Innanzitutto apriamo l'Editor di Visual Basic (da ora in poi chiamato EVB)e dal menu inserisci aggiungiamo un "modulo".
Il modulo possiamo dire che e' la programmazione vera e propria o, per meglio dire che e' un modo per programmare Excel.
ora scrivo il programma, poi vi spieghero' il dettagli di esso.
Sub provamacro() '1
Range("A1").Select '2
prova = ActiveCell '3
MsgBox ("La cella A1 di questo foglio contiene la seguente scritta: " & prova) '4
End Sub '5
Questo testo copiatelo nel modulo creato.
Scrivete una qualsiasi parola nella cella "A1" del foglio Excel e eseguite la macro.
Per eseguire la macro andate alla finestra excel e fate "Strumenti", "Macro" , "Macro..." e scegliete la macro "provamacro".
Oppure da EVB cliccate sul tastino play.
La struttura del programma e' cosi' composta:
tutte le parolo in fondo a una riga dopo il simbolo ' servono da "MEMO" (conosciuti anche com REM) e non verranno eseguite dal programma. In questo esempio abbiamo dei numeri, servono solo ad identificare il numero di riga per darvi maggiori spiegazioni.
Riga 1.
Sub provamacro() '1
Questa riga dice che la macro in questo foglio si chiama "provamacro".
Riga 2.
Range("A1").Select '2
In questa riga diciamo ad Excel di andare alla casella A1 del foglio che stiamo visualizzando.
Riga 3.
prova = ActiveCell '3
In questa riga diciamo che la variabli "prova" conterra' quello che c'e' scrito nella cella attiva (che la abbiamo selezionata nella riga precedente).
Riga 4.
MsgBox ("La cella A1 di questo foglio contiene la seguente scritta: " & prova) '4
In questa riga diciamo di creare una finestra di messaggio con scritto all'interno quello che abbiamo messo tra virgolette e, aggiungendo con la "&" la variabile che abbiamo definito nella riga precedente.
Riga 5.
End Sub '5
In questa riga diciamo che il programma e' finito.
So che alcuni di voi mi staranno dando della imbecille, ma vorrei che sin dall'inizio le basi siano ben chiare perche' NON ci ritornero' piu' a spiegarle.
Nelle seguenti lezioni di programmazione, verranno spiegate le righe accanto all'istruzione o durante il programma utilizando il simbolo spigato '.
Baci Baci.
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [L'APPRENDISTA STREGONE] #00 - 18/12/2000 |
| CODING 4 DUMMiEZ: VB e risoluzione degli host [JEYoNE] 0x0C/0x0E |
+-------------------------------------------------------------------------------+
--COME OTTENERE UN HOST DA UN IP ADDRES IN VISUAL BASIC--
Questo è un semplice programmino scritto in visual basic, per
ottenere un Host
Name da un IP Address.
Il codice riportato qui sotto è stato preso in visione dal sito
VBnet Network.
Tutti i copyright sono dell'autore Randy Birch, e non sono miei,
voglio chiarire
subito questa cosa, prima di avere disguidi o battibecchi con
qualcuno.
Chiarito questo possiamo cominciare:
Il form di questo piccolo programma dovrebbe essere rappresentato
più o meno in
questo modo:
________________________________________________________________________________
_____________________________
| Host Name from IP Addres |
|_____________________________|
| ________________ |
| Addres |________________| | <--- Text1
| ________________ |
| Host |________________| | <--- Text2
| |
| _____________ |
| |Get Host Name| | <--- Command1
| |_____________| |
| |
|_____________________________|
________________________________________________________________________________
Nel form inserire un command button (command 1) e due text box
(Text1 e Text2) e
inserire questo codice:
________________________________________________________________________________
Option Explicit
Private Sub Command1_Click()
Text2.Text = GetHostNameFromIp (Text1.Text)
End Sub
________________________________________________________________________________
Inserite questo codice in un modulo BAS
________________________________________________________________________________
Option Explicit
Private Const WSADescription_Len = 256
Private Const WSASYS_Status_Len = 128
Private Const WS_VERSION_REQD As Long = &H101
Private Const IP_SUCCESS As Long = 0
Private Const SOCKET_ERROR As Long = -1
Private Const AF_INET = 2
Private Type WSADATA
wVersion As Integer
wHighVersion As Integer
szDescription(0 To WSADescription_Len) As Byte
szSystemStatus(0 To WSASYS_Status_Len) As Byte
imaxsockets As Integer
imaxudp As Integer
lpszvenderinfo As Long
End Type
Private Declare Function WSAStartup Lib "wsock32.dll" _
(ByVal VersionReq As Long, _
WSADataReturn As WSADATA) As Long
Private Declare Function WSACleanup Lib "wsock32.dll" () As Long
Private Declare Function inet_addr Lib "wsock32.dll" _
(ByVal s As String) As Long
Private Declare Function gethostbyaddr Lib "wsock32.dll" _
(haddr As Long, _
ByVal hnlen As Long, _
ByVal addrtype As Long) As Long
Private Declare Sub CopyMemory Lib "kernel32" _
Alias "RtlMoveMemory" _
(xDest As Any, _
xSource As Any, _
ByVal nbytes As Long)
Private Declare Function lstrlen Lib "kernel32" _
Alias "lstrlenA" _
(lpString As Any) As Long
Public Function SocketsInitialize() As Boolean
Dim WSAD As WSADATA
SocketsInitialize = WSAStartup(WS_VERSION_REQD, WSAD) = IP_SUCCESS
End Function
Public Sub SocketsCleanup()
If WSACleanup() <> 0 Then
MsgBox "Windows Sockets error occurred in Cleanup.",
vbExclamation
End If
End Sub
Public Function GetHostNameFromIP(ByVal sAddress As String) As String
Dim ptrHosent As Long
Dim hAddress As Long
Dim nbytes As Long
If SocketsInitialize() Then
hAddress = inet_addr(sAddress)
If hAddress <> SOCKET_ERROR Then
ptrHosent = gethostbyaddr(hAddress, 4, AF_INET)
If ptrHosent <> 0 Then
CopyMemory ptrHosent, ByVal ptrHosent, 4
nbytes = lstrlen(ByVal ptrHosent)
If nbytes > 0 Then
sAddress = Space$(nbytes)
CopyMemory ByVal sAddress, ByVal ptrHosent, nbytes
GetHostNameFromIP = sAddress
End If
Else: MsgBox "Call to gethostbyaddr failed."
End If
SocketsCleanup
Else: MsgBox "String passed is an invalid IP."
End If
Else: MsgBox "Sockets failed to initialize."
End If
End Function
________________________________________________________________________________
Torno a dire che questo codice non è mio, ma è di proprietà di Randy
Birch, non
voglio prendere i meriti di nessuno, questo è suo, e suo rimane.
Spero di essere stato utile a qualcuno, probabilmente nel prossimo
numero ci sarà
un altro programmino in visual basic, ma chi lo sa....magari per il
prossimo
numero non ci sarò più! :)))
BYEZ ALL
JEYoNE
jey1@SoftHome.net
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [L'APPRENDiSTA STREG0NE] #00 - 18/12/2000 |
| CRACKiNG 4 DUMMiEZ: Cracking 4 totally newbies [_ph0b0s_] 0x0D/0x0E |
+-------------------------------------------------------------------------------+
************************************************************************
* -=CRACKING FOR TOTALLY NEWBIES=- *
* (lesson 1) *
* *
* WRITTEN BY PHOBOS (AKA D4rKSP4rr0W) *
* PROUDLY MEMBER OF HackManiaCi StoRe(c) *
* *
* COPYRIGHT 1999/2000 ALL RIGHT RESERVED. *
* (non e' vero... ma fa molto figo!!! ;)) *
************************************************************************
Salve a tutti,
Molti di voi avranno sicuramente trovato e letto, centinaia di
tutorials sul cracking delle applicazioni, giochi e tutto quello che
riguarda il magico mondo dei computer (basta andare su un motore di
ricerca e immettere come parole chiave cracking tutorials, ne
appariranno decine di migliaia).
Questo e il primo di una serie di tute che spero sia un po piu
diverso dagli altri, infatti, la maggior parte di questi ultimi sono o
mirati sul cracking di una particolare applicazione identificando il
meccanismo di protezione di questa, o sono in inglese (che non
costituisce un grosso problema al giorno doggi, ma volete mettere la
cara vecchia lingua di papa Dante? ;) ) oppure peggio ancora sono di
entrambi i tipi visti sopra, insieme.
Ora la mia pretesa non e quella di scrivere un vero e proprio tute con
tutte le possibili strade che si possono intraprendere cercando di
craccare un programma (sarebbe unopera troppo vasta, e le mie
conoscenze da sole non sarebbero sufficienti per affrontarla tutta) ma
quella di riuscire ad instradare (sulla base di quelli che sono stati i
miei errori quando ho cominciato ad affacciarmi su questo affascinante
mondo) quelli di voi che sono alle prime armi, su come affrontare
situazioni che generalmente si presentano quando si ha a che fare col
reverse engeneering, e perche no, darvi qualche diritta per rendere
piu mirato il vostro attacco ad un programma.
Un solo avviso, non sperate di trovare la luce alla fine del tunnel
leggendo queste lezioni, che sono scritte per coloro che non hanno molta
dimestichezza con debugger e altri simili tools, per diventare bravi
dovrete studiare molto materiale, e soprattutto esercitarvi tantissimo
e con i piu svariati tipi di applicazioni, in modo da ampliare la
vostra esperienza e conoscenza sullargomento. Quindi se avete
allattivo gia una media conoscenza dei meccanismi di protezione e
delluso dei debugger, potete risparmiarvi di leggere, oppure se
volete fare una cosa costruttiva, leggete e poi mandatemi le vostre
opinioni e/o i vostri consigli per migliorarle. OK?
************************************************************************
* LEZIONE UNO: GLI STRUMENTI INDISPENSABILI *
************************************************************************
Bene, passiamo ora alla sezione Srumenti necessari, innanzi tutto vi
serve un debugger che funzioni in (come si dice in gergo) real mode,
io uso il SoftICE della Numega, questo strumento serve per esaminare i
programmi mentre questi sono eseguiti, e seguire da vicino tutto quello
che succede dentro quella amena e rumorosa scatola di metallo che viene
chiamata computer, permettendovi di prendere il controllo della
situazione o modificare praticamente tutto (in barba al kernel di
windows 9X). Un altro strumento utile e il WinDASM, questultimo e
presente dappertutto in rete in versione demo ma attenzione alle
limitazioni di questultima che sul piu bello del tracing ti blocca
dicendoti che il numero di operazioni della versione demo e limitato,
quindi se ne avete la possibilita procuratevi la versione integrale
(che tra laltro consente di salvare il file disassemblato come testo
o, volendo, di stamparlo (he he he, provateci con un eseguibile di 900
Kbyte ;)) che non ha nessuna limitazione, anche in questo caso io uso
la versione 8.9 che comprende anche un debugger ma che francamente io
trovo decisamente inefficace (comunque, come si dice, de gustibus...),
avete anche bisogno di un editor in grado di modificare gli eseguibili
per patchare i programmi che dovrete craccare, di questi strumenti ce
ne sono centinaia, io ne ho installati un paio, dei due trovo molto
funzionale l'Ultra Edit 32scritto da 'D. Mead' (www.ultraedit.com)
(ha tanti accorgimenti e piccolezze che rendono simpatico un programma.)
************************************************************************
* CONFIGURAZIONE DEL SOFICE *
************************************************************************
Bene, bene, benissimo cominciamo col vedere come e possibile
migliorare i tools che abbiamo a disposizione.
Il SoftICE e un debugger che, funzionando in modalita real time
deve essere caricato in memoria prima del sistema operativo, quindi,
dopo linstallazione, allinterno del file Autoexec.bat sara
presente la riga di comando che avvia lICE, quindi a meno che non
usate il computer solo ed esclusivamente per fare i crackers, potrebbe
tornarvi utile un menu in fase di avvio del sistema che vi permetta di
scegliere se avviare o meno il SoftICE.
Se non avete dimestichezza con la programmazione mediante file di
Batch vi riporto le righe che avviano questo menu:
----------- 8<-------------- TAGLIA QUI ------- 8<-------------------
CLS
ECHO START WIN ICE ?
C:\WINDOWS\COMMAND\CHOICE /T:N,5 <----- Modificate questo percorso in
quello dove avete i comandi
MS-Dos
IF ERRORLEVEL 2 GOTO SKIPICE
C:\SIW95\WINICE.EXE <------------------ Modificate questo percorso in
quello dove avete istallato
lICE
GOTO END
:SKIPICE
ECHO NUMEGA SOFTICE SKIPPED...
ECHO STARTING WINDOWS WITHOUT DEBUGGER.
:END
----------- 8< ------------ TAGLIA QUI -------- 8<-------------------
Questo menu, (che potete tranquillamente tagliare ed incollare nel
file autoexec.bat al posto della sola riga di comando
C:\SIW95\WINICE.EXE che viene inserita dal setup del SoftICE,
ricordando, chiaramente, di togliere i commenti che ho inserito io,
altrimenti vi succede il putiferio in avvio ;)) chiede se avviare il
SoftICE, se scegliete S lo avvia (sono un genio :p ), se scegliete N
no, mentre se non rispondete nulla, dopo cinque secondi di attesa, il
menu sceglie automaticamente di non avviare lICE (scelta di default:
No).
A questo punto e possibile andare a modificare la configurazione del
SoftICE, o aprendo lapplicazione Symbol loader presente nel
pacchetto e andando ad intervenire sulle voci presenti allinterno
delle opzioni in Edit e poi in SoftICE initialization settings,
oppure andando a modificare il file (contenuto nella directory dove
lICE e stato installato, solitamente [DRIVE]:\Sicew95\) winice.dat
Questo file contiene tutte le informazioni che il SoftICE utilizzera
allavvio e durante il suo uso.
Di seguito vi riporto la copia del mio file, commentandovi i punti
salienti. Questo file e gia ottimizzato secondo le mie necessita, se
queste dovessero coincidere con le vostre, sara sufficiente tagliare
il testo e incollarlo in un file del blocco note di windows che andra
poi salvato con il nome di winice.dat
--------- 8< ------------- TAGLIA QUI ---------- 8<-------------------
PENTIUM=ON
NMI=ON
ECHOKEYS=OFF
NOLEDS=OFF
NOPAGE=OFF
SIWVIDRANGE=ON
THREADP=ON
LOWERCASE=OFF
WDMEXPORTS=OFF
MONITOR=0
PHYSMB=128
SYM=2048
HST=256
TRA=128
MACROS=32
DRAWSIZE=2048
INIT="faults off;X;set font 2;lines 41;wc 21;wd 10;code ON;wr;cls;"
F1="h;"
F2="^wr;"
F3="^src;"
F4="^rs;"
F5="^x;"
F6="^ec;"
F7="^here;"
F8="^t;"
F9="^bpx;"
F10="^p;"
F11="^G @SS:ESP;"
F12="^p ret;"
SF3="^format;"
CF8="^XT;"
CF9="TRACE OFF;"
CF10="^XP;"
CF11="SHOW B;"
CF12="TRACE B;"
AF1="^wr;"
AF2="^wd;"
AF3="^wc;"
AF4="^ww;"
AF5="CLS;"
AF8="^XT R;"
AF11="^dd dataaddr->0"
AF12="^dd dataaddr->4"
CF1="altscr off lines 60 wc 32 wd 8;"
CF2="^wr^wd^wc;"
;LOAD=c:\windows\system\user.exe
;LOAD=c:\windows\system\gdi.exe
;LOAD=c:\windows\system\krnl386.exe
;LOAD=c:\windows\system\mmsystem.dll
;LOAD=c:\windows\system\win386.exe
;***** Examples of export symbols that can be included *****
;Change the path to the appropriate drive and directory
EXP=c:\windows\system\vga.drv
;EXP=c:\windows\system\vga.3gr
;EXP=c:\windows\system\sound.drv
EXP=c:\windows\system\mouse.drv
;EXP=c:\windows\system\netware.drv
EXP=c:\windows\system\system.drv
EXP=c:\windows\system\keyboard.drv
EXP=c:\windows\system\toolhelp.dll
EXP=c:\windows\system\shell.dll
EXP=c:\windows\system\commdlg.dll
EXP=c:\windows\system\olesvr.dll
EXP=c:\windows\system\olecli.dll
EXP=c:\windows\system\mmsystem.dll
;EXP=c:\windows\system\winoldap.mod
EXP=c:\windows\progman.exe
EXP=c:\windows\drwatson.exe
;***** Examples of export symbols that can be included for Windows 95
;*****
;Change the path to the appropriate drive and directory
EXP=c:\windows\system\kernel32.dll
EXP=c:\windows\system\user32.dll
EXP=c:\windows\system\gdi32.dll
EXP=c:\windows\system\comdlg32.dll
EXP=c:\windows\system\shell32.dll
EXP=c:\windows\system\advapi32.dll
;EXP=c:\windows\system\shell232.dll
EXP=c:\windows\system\comctl32.dll
EXP=c:\windows\system\crtdll.dll
EXP=c:\windows\system\version.dll
;EXP=c:\windows\system\netlib32.dll
EXP=c:\windows\system\msshrui.dll
;EXP=c:\windows\system\msnet32.dll
EXP=c:\windows\system\mspwl32.dll
EXP=c:\windows\system\msvbvm50.dll
EXP=c:\windows\system\vb40032.dll
EXP=c:\windows\system\mpr.dll
EXP=c:\windows\system\wsock32.dll
EXP=c:\windows\system\ole32.dll
EXP=c:\windows\system\msvcrt40.dll
EXP=c:\windows\system\msvcrt20.dll
EXP=c:\windows\system\mfc42d.dll
EXP=c:\windows\system\mfc042d.dll
EXP=c:\windows\system\msvcrtd.dll
;WINICE.DAT
;(SIW95\WINICE.DAT)
;for use with SoftICE Version 3.2 (Windows 95) 14 July 1997
;**********************************************************************
;If your have MORE than 32MB of physical memory installed, change the
;PHYSMB line to the correct # of Megabytes.
;If you have LESS than 32MB you can save a bit of memory by specifying
;the correct # of Megabytes Example: PHYSMB=32
;**********************************************************************
;***** Examples of sym files that can be included if you have the SDK
;***** Change the path to the appropriate drive and directory *****
-------- 8< ------------- TAGLIA QUI ------- 8<--------------------
Le prime righe (quelle fino alla stringa INIT= vanno lasciate come
sono se avete un processore pentium (o compatibile) o successivo, (se
cio non e vero, ad esempio se avete un 80486, semplicemente settate
su OFF la voce PENTIUM) le uniche stringhe che ci interessano sono:
quella che setta il LOWERCASE su on o off: impostandola su on si
ottiene che il debugger utilizzi le lettere minuscole, viceversa se la
si imposta su off; e quella che setta le dimensioni della memoria RAM
del computer PHYSMB dove il numero alla destra deve essere posto
uguale al quantitativo in megabyte della memoria presente sulla
macchina.
Per quanto riguarda la stringa INIT= questa e quella responsabile
della personalizzazione della finestra dellICE.
Vediamo come si interpretano i comandi in essa contenuti:
Faults [off | on] questo comando se settato su off, impedisce allICE
di intervenire, nel caso si verifichino errori del kernel del sistema
operativo, di pagina non valida, ecc. e poiche non e raro che questo
accada, conviene impostarlo su off, se non volete resettare il sistema
ogni qual volta il kernel di windows decida che qualche applicazione ha
compiuto una operazione non valida e verra terminata... (piu tecnico:
nel caso di general protection faults).
'X' questo comando riporta il controllo al sistema operativo.
NOTA: tutti i parametri che vengono inseriti nella stringa INIT prima
del comando X, sono eseguiti nella fase di boot del sistema, mentre
quelli che seguono la X, vengono eseguiti al primo avvio del debugger.
Set font [1 | 2 | 3] Seleziona il tipo di carattere che verra
utilizzato dallICE (la 2 e quella che a me piace di piu)
Lines Setta il numero di righe della finestra del debugger (nel mio
caso, con una risoluzione di 800x600 e con il tipo di font settato su
2, con quarantuno linee, la finestra occupa tutto lo schermo)
wc Attiva e dimensiona la finestra del codice disassemblato, potete
scegliere il numero di righe che piu preferite.
wd Attiva e dimensiona la finestra con il dumping esadecimale della
memoria (in parole povere il contenuto della memoria in codice
esadecimale byte per byte)
wr Attiva la finestra che mostra i registri della CPU (indispensabile
come le altre due)
cls ripulisce lo schermo (come nel caro buon vecchio DOS :) )
Unocchiata alle funzioni assegnate ai tasti F8, F10, F11:
F8 permette di seguire un single stepping entrando nelle procedure
chiamate dalle istruzioni CALL
F10 single stepping come sopra ma con la differenza che le CALL
vengono eseguite senza che sia necessario entrare in esse, (in parole
povere, le istruzioni e subroutines presenti in una call, vengono
eseguite in una sorta di background e lICE si riporta
automaticamente alla istruzione immediatamente successiva alla data
Call)
F11 Permette di ritornare alla istruzione immediatamente successiva ad
una Call (ne vedremo un utilizzo pratico piu avanti).
Le altre linee presenti nel file servono allICE per caricare (e
soprattutto per permettergli di riconoscere) le funzioni importate di
windows, cosa sono le funzioni importate? Sono tutte quelle funzioni
che costituiscono linterfaccia grafica del sistema operativo e che
permettono a questultimo di interagire con programmi ed utente
mediante le finestre, la pressione dei pulsanti, luso del mouse, ecc.
ecc. (e che permettono di sproteggere i programmi ;) !!); quindi, a
meno che non abbiate configurazioni particolari del computer (nel qual
caso vi consiglio di cercare in rete il manuale del SoftICE), potete
tranquillamente lasciarle nella configurazione che vedete sopra, con
lunica accortezza, di cambiare il percorso (path) mettendo quello
corrente del vostro sistema operativo (ad esempio, se avete due HD e il
windows e installato su quello chiamato D, dovete cambiare la lettera
C in D, nel percorso di ogni singola funzione, nel file winice.dat,
altrimenti lICE non trovera un kakkio!).
Aggiungo anche un breve Quick Command Reference sui comandi che
utilizzeremo nel SoftICE.
************************************************************************
* SoftICE quick command reference *
************************************************************************
Bpx : (breakpoint on execution) significa che lICE deve intervenire e
fermare lesecuzione del programma nel caso si verifichi una data
condizione specificata dopo il comando (i dettagli dopo, questo e un
Quick Reference ;) )
Bpm : (breakpoint on memory) funziona su un accesso alla memoria in un
dato indirizzo (possiamo utilizzarlo per vedere se una funzione legge o
scrive su un determinato indirizzo)
Bpr : (breakpoint on memory range) come il precedente ma funziona su di
una serie di indirizzi (su un range di memoria)
Bpio : (breakpoint on Input/Output) funziona su un accesso I/O
Bpint : (breakpoint on interrupt) su un interrupt (che sono dei vettori
che controllano, laccesso alle periferiche)
Bmsg : (breakpoint on message) fa intervenire lICE su un messaggio (lo
useremo per brekkare su funzioni come WM_GETTEXT).
Task : Questo comando visualizza tutti i processi attivi, viene in
genere utilizzato in combinazione con Hwnd.
Hwnd : Mostra l'handle delle finestre di un determinato programma.
Gli handle sono, in parole povere, dei numeri che identificano una
data finestra in un programma, ogni finestra (dalla nag screen alla
main o principale del programma ) e identificata univocamente da un
handle. Questi risultano indispensabili per identificare le finestre
che vorremmo rimuovere (ad esempio una NAG = FINESTRA_FASTIDIOSA_CHE_TI
APPARE_PER RICORDARTI_CHE_DEVI_COMPRATELO_IL_PROGRAMMA) da un dato
programma.
bd* : Disabilita tutti i bp, il simbolo star può essere sostituito
con il numero identificativo del breakpoint
be* : Abilita tutti i breakpoints il resto è uguale a "bd"
bl : Lista tutti i breakpoint che stiamo usando ed il loro numero
identificativo, se il break e preceduto da un * allora vuol dire che
e disabilitato
bc* : Cancella tutti i breakpoints, la sintassi e come bd e be
bh : Ci mostra tutti i breakpoints che abbiamo utilizzato nelle
sessioni precedenti del SoftICE
? [valore | registro] : Ci permette di valutare una data espressione o
vedere quale valore e contenuto in un dato registro, ecc.
d [indirizzo] : permette di avviare il dumping esadecimale di una
data locazione di memoria, per mostrarci cosa essa contiene
(chiaramente in codice esadecimale)
a [indirizzo] : ci permette di modificare ciò che si trova ad un dato
indirizzo (agendo sui caratteri)
e [indirizzo] : (edit indirizzo), come sopra, con la differenza che
bisogna intervenire sui valori esadecimali.
************************************************************************
* Cenni sul WinDasm e su IDA *
************************************************************************
Per quanto riguarda il WinDasm, la differenza fondamentale tra questo
software e il SofICE, e' che il windasm e' un disassembler, cioe' un
disassemblatore, il suo 'compito' e' quello di mostrare un 'listato' di
tutte le istruzioni in assembler (il linguaggio del processore) che ci
ritornera' molto utile, quando dovremo avere un approccio ad un
programma in (come si dice in gergo) 'Dead List'.
Infatti, ci saranno schemi di protezione, che potranno essere
disabilitati, semplicemente andando a controllare le istruzioni
dell'eseguibile, senza la necessita' di utilizzare il debugger.
Altra differenza di non poco conto e' che il windasm da una lista
'morta' del programma, mentre l'ice, ne permette l'analisi istruzione
per istruzione, dandoci la possibilita' di controlloare quali dati
vengono elaborati, modificati e salvati... in parole povere, l'ice e'
indispensabile se vogliamo capire come venga generato un codice seriale
per un programma.
All'inizio, utilizzaremo il WinDasm, poi quando saremo diventati piu'
bravi, inizieremo ad utilizzare IDA un disassemblatore (IL
disassemblatore) che vi fara' dimenticare windasm (anche se io
preferisco windasm... ma devo ammettere che non sono paragonabili... ida
e' il migliore :/)
Puff.. puff...
Per ora e' tutto, ho finito le sigarette e devo uscire a comprarle...
quindi sarete costretti ad aspettare la prossima 'zine per sapere chi e'
l'assassino... ahem... per entrare meglio nel vivo della situazione,
magari con qualche esempio... ;)
Nel frattempo iniziate a familiarizzare con i tools che vi ho descritto,
se non ce li avete ancora, iniziate a procurarveli, in seguito vi posto
una lista di indirizzi utili:
http://go18.163.com/~cracking/debuggers.htm (tutte le ver. del SofICE)
http://protools.cjb.net (tutto cio' che serve)
http://phrew.cjb.net (in cui trovate la copia originale di questo doc.)
http://www.suddendischarge.com (tanti tools)
http://www.astalavista.com (motore di ricerca 'underground')
http://www.uic-spippolatori.com (il meglio per il reversing)
************************************************************************
* NOTE FINALI: Ringrazio tutti coloro che mi hanno aiutato, e che *
* continuano ad aiutarmi a comprendere questo affascinante mondo. (non *
* vi elenco tutti ragazzi, perche' se no le note finali mi vengono *
* lunghe come la treccani ;) *
* Ricordo al lettore che tutto il materiale contenuto nelle lezioni *
* e' a solo scopo didaddico, non mi assumo, inoltre, nessuna *
* responsabilta' se vi fate saltare programmi e sistemi operativi. Per *
* commenti, domande (intelligenti!!) e critiche: phobos333@hotmail.com *
************************************************************************
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
+-------------------------------------------------------------------------------+
| ONDAQUADRA MAGAZINE ~ [SHUTD0WN] #00 - 18/12/2000 |
| ETiCA [Tdi110CV] 0x0E/0x0E |
+-------------------------------------------------------------------------------+
#######################################
# ++++++++++++++++++++++++++++++ #
# + Un po' di lezione sull'etica + #
# ++++++++++++++++++++++++++++++ #
#######################################
Autore : TDI110CV
Luogo : Ufficio
Orario : 13.30 (pausa !!!)
e-mail : tdi110cv@iname.com
Telefono : +8888 - 88
____________________________________________________________________________
Carissimi lettori , questo secondo articolo in questa prima uscita di OQ
lo scrivo semplicemente perchè ... ehmmm ... e perchè lo scrivo ?
Vabbè lasciamo perdere ! Diciamo che voglio mettere i puntini sulle I !!
Il punto e' questo !!!! Tutti tentano , cercano , ci provano , insomma molta
gente prima o dopo si chiede che cos'è l'hacking !
Tantissimi arrivano a pensare che l'hacking e' una cosa illegale e che non
va bene (mi domando quanti deficenti ci sono al mondo) , altri invece
pensano la stessa cosa e proprio perchè e' una cosa che non va bene
cominciano a smanettare come disperati ! (il fascino della trasgressione !!)
Inoltre ci sono quelli convinti che l'hacking sia una attivita' che viene
praticata da una certa schiera politica !
Pensate che ad un certo punto che io e jey stavamo discutendo su una certa
cosuccia , nel nostro canale , entra un bel personaggio di cui non faccio il
nick (questione di privacy hihihi) e mi dice :" ma voi ... e' si voi
siete hacker !"
Io rispondo :" noi hacker ? Cosa vuol dire ? "
Bene questo convinto del fatto che fossimo li per chissa' cosa , comincia
a sparare cazzate del tipo :
"bè gli hacker sono persone che non fanno altro che penetrare i sistemi
informatici altrui e distruggerli ! Gli hacker sono persone di sinistra che
vorrebbero che tutto fosse libero e gratuito !"
Alchè io e jey ci prendiamo in query chiedendoci che stronzate stesse tirando
fuori il coglionazzo !
Ora questo per spiegare che razza di malainformazione ci subiamo tutti
i giorni attraverso gli strumenti dei mass media !!
Secondo questa gente io non potrei essere un estremista di destra che crede
che la terra dove vive dovrebbe essere uno stato a se stante e cmq dilettarmi
a fare hacking !
E ricordate che fare hacking non vuol certo dire penetrare una fig ... ehmmmm
volevo dire un sistema informatico e distruggerlo !
Questo e' quello che i mass media vi vogliono far credere ! Ci disegnano come
persone senza scrupoli , persone che danneggiano le aziende e il mondo
intero !
Bene credete che i cosidetti hacker (come li chiama la gente) che compiono
azioni simili non sono certo degli hacker come li intendiamo noi !
Una definizione per tali persone sarebbe : LAMER (detti anche coglioni).
Insomma tutto questo per far capire che non esiste un rootkit , ops scusate
volevo dire identikit dell'hacker !
Ci si diletta nell'hacking facendo anche cose del tutto legali ! Non per forza
bisogna bucare server o roba del genere !
Ci si puo' fare un trojan , modificare il proprio linux , pensare e
riflettere su cosa succederebbe se al mio sever facessi una tal modifica !
Insomma un hacker che si rispetti non usa le sue capacita' per creare danni o
o per fare truffe , e neppure per sentirsi al di sopra di qualcun ' altro !
Insomma che male c'è se tutto cio' che si fa lo si fa per cercare di capire
come funzionano le cose sulla rete ?
Si magari si puo' anche smanettare con qualche smurf o qualche trojan , pero'
anche in questo caso , che cosa c'è di male se lo scopo e' verificare come e'
stato codato ?
Qualcuno ora pensera' che io non sono un hacker se non faccio determinate
cose ! INFATTI IO NON SONO UN HACKER ! Sono solo uno dei tanti smanettoni
che ogni tanto si mette in testa qualche cosa e vuole arrivarci in fondo !
l'hacker e' qualche cosa di irraggiungibile e' la perfezione assoluta ,
, una mente piu' elevata di tutte le altre .
Sicuramente non si arrivera mai a tali livelli , ma certo lo scopo non e'
questo ! L'unica scopo e' mettere a nudo cio' che la gente usa normalmente !
Ci troviamo a usare strumenti dei quali conosciamo solo i nomi !
Non si sa neppure cosa ci sia un client SMTP !
Provate a chiederlo a chiunque ! Vedrete cosa vi rispondera' !
E magari questa sfortunata persona che avete beccato per strada e' un manager
di una societa' di informatica che usa tutti i giorni Microshitt OUTLOOK.
Si certo perchè questo e' uno dei client SMTP che ci sono al mondo !
E vi garantisco che queste cose sono roba di tutti i giorni ! Io stesso mi
trovo a contatto con dei fantomatici sistemisti che a sentir parlare di certe
cose mi domandano se si mangiano !
Basti pensare all'FTP che mi ritrovo in azienda !
In due minuti ...(cercate di capire) e nessuno che mi sta' ad ascoltare !
Insomma lo scopo e' arrivare a capire cosa stiamo utilizzando , per creare
qualche cosa di nostro , imparare ad analizzare le cose , capire i protocolli
di trasmissione , i vari O.S. e sopratutto per cercare di non essere
manovrati come burattini , da parte di chi ha un unico sopo !!! Fare
solamente una infinita' di soldi ! Badate bene che questo non sarebbe in
se' un brutto obbiettivo , il punto critico sono i metodi che spesso si
si arriva ad utilizzare per raggiungere tale traguardo !!!!
Imparate a pensare con la vostra testa ! Cercate di distinguervi ,
utilizzate delle vostre metodologie , imparate , ma soprattutto imparate ad
ad imparare ! E non entrate in particolari discorsi politici ! A me
personalmente queste cose danno molto fastidio ! Pensare che la gente mi
consideri di una certa schiera politica solo perchè smanetto un pochino , mi
fa rabbrividire ! Si infatti rabbrividisco quando mi trovo a parlare con delle
delle persone cosi' ignoranti !
Insomma Costruitevi un obbiettivo e cercate di raggiungerlo !
Fatevi consigliare , accettate consigli da tutti , ma non cercate le
cose gia fatte !
Questo e nient'altro ho da dirvi !!!
Alla prossima uscita ! Nella quale Vi parlero' di un argomento molto CooL !
Sempre se riusciro' a terminare un CGI scanner Davvero Rivoluzionario !
--- TDI110CV ---
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
+-------------------------------------------------------------------------------+
| oq~staff: |
| AndreaGeddon ~ HTB ~ JEYoNE ~ Malkavian |
| Mysha ~ Phobos ~ Tdi110cv ~ Tin_Man ~ Tritemius |
| |
+-------------------------------------------------------------------------------+
| http://ondaquadra.cjb.net ~ ondaquadra@hackmaniaci.com |
+-------------------------------------------------------------------------------+
