Chiunque voglia far parte dell'Open C6 Project è il benvenu- to. Il progetto si occupa di creare clients e servers C6 open source e della massima portabilità (creati in c/c++ o java). Per maggiori informazioni, troverete tutto nella sezione pro- getti di www.redangel.it (al momento il link non è ancora at- tivo).
==--> C6, Come sei? <--==
Questo testo è stato scritto per soli scopi educativi, non mi assumo nessuna responsabilità per usi illeciti di questo te- sto. Inoltre il reversing del c6 non è reato in quanto non essendoci alcun genere di condizioni da accettare (e neppure nella guida è scritto nulla a riguardo), è possibile disasse- mblare, crackare e fare il reversing di ogni parte del c6. Tuttavia, il software è protetto da copyright, quindi la co- pia è vietata.
Inoltre, ho fatto questo lavoro solo per utilizzare C6 in LAN (usando un server locale) e sotto Linux (codandolo in C). Al- tri utilizzi potrebbero essere illegali! Altr scopo di questo testo è mostrare quante informazioni vengono passate dal client al server che potrebbe benissimo loggare o 'attivarsi' alla lettura di determinate parole, proprio come fa Echelon. Con questo non voglio assolutamente insinuare che la tin ci spia e viola la nostra provacy, anzi già dal fatto che non chieda molte informazioni alla nostra iscrizione si può intuire che io mi sbagli, ma voglio solo mostrarvi le informazioni passate (nostre informazioni) al server.
Finalmente il sogno di tanti presunti hackers, crackers, re- versers, coders e chi più ne ha più ne metta, si avvera. Il protocollo di C6 è stato reversato nelle sue funzioni più importanti. Le funzioni ancora da reversare sono:
- Codifica iniziale - Codifica della password - Varie funzioni come ricerca di NetFriends e Canali.
Potrà sembrarvi molto il lavoro ancora da fare, ma invece è abbastanza poco. La codica del C6 è del tipo cifrario di Ce- sare, quindi estremamente semplice da crackare. Per la codi- fica della password per il momento non ho approfondito più di tanto, poichè stavo pensando di aggirare il problema. Essendo il protocollo ancora in fase di reversing, non sono ancora riuscito a reversarlo del tutto.
Volevo, prima di parlare del protocollo,
esprimere alcune mie idee: quanti di noi si definiscono hacker (dico noi nel
senso di 'noi che siamo nell'underground', dato che io non lo fac- cio) e alla
fine non sanno fare nulla? Questo stesso proto- collo l'ho reversato in soli
DUE giorni: una serata per eli- minare la codifica ed un giorno per comprendere
a fondo i co- mandi qui analizzati. Ne ho sentite tante, ma davvero tante sul
C6 e voglio farvi vedere qualche esempio. Innanzitutto per coloro che sono soliti
frequentare l'ormai famoso news- group free.it.hackers volevo segnalare ad esempio
un messaggio (scusate ma quando i nomi ci vogliono, ci vogliono: che significato
avrebbe altrimenti la sezione 'saluti' pre- sente in quasi tutti i tutorials?)
di uno che pensavo fosse esperto: ******.. Questo stesso ****** ha affermato
che il c6 usa il protocollo SSL per codificare i dati trasmessi. Tutto questo
è falso e vi sarà mostrato di seguito (seguire per credere :).
Oltretutto basterebbe usare lo snif- fer per notare che molti dei bytes di quando
si invia un mes- saggio restano perfettamente uguali, cambia veramente poco.
se si trattasse di SSL, cambierebbe completamente tutto senza avere elementi
logici di connessione (da un log ad un altro). Continuando, tale
******, sempre nello stesso thread dice che il server è blindatissimo
e che conviene lasciar perdere in partenza. Sempre continuando nello stesso
thread, dopo che ****** ha detto che occorre il ciclope per crackare l'SSL e
che Steve dica che c'è bisogno di una grande potenza di cal- colo per
utilizzare questo ciclope, ****** afferma che è un tool per il calcolo
distribuito. Più avanti vedremo che per reversare il c6 e creare un server
basta azzerare la chiave di codifica e per creare un client basta capire come
funziona l'algoritmo di codifica che usa quella chiave. Se il client C6 ci mette
praticamente niente per decodificare il testo co- dificato, lo stesso potrà
fare il nostro. Per coloro che vo- gliano approfondire garantisco io, l'algoritmo
mi sembra mol- to facile. Passiamo ora al protocollo. Come ho fatto a capire
che si trattava di cifrario di cesare? Semplice, come ho già detto se
si usa uno sniffer, un cumulo di dati (tra l'altro solo quelli client-server
sono codificati) sono uguali (inviando due volte un messaggio, lo sniffing è
quesi identico!). Se fosse SSL cambierebbe del tutto, ed è proprio questo
che mi ha spinto alla decodifica. Come primo pacchetto, il server manda al client
la chiave di codifica (e qui c'è da dire che c'è qualcuno di cui
non ri- cordo il nick che insisteva dicendo che lui non avrebbe man- dato la
chiave di codifica al client, ma invece è così) al client. La
chiave sono gli ultimi 8 bytes. Azzerando questi, cioè impostandoli come
bytes 00 si otterrà il testo in chiaro e, dato che così sarà
più facile, è proprio così che lavore- remo. C'è
poi da dire che tutte le comunicazioni client-serv. cominciano con l'hex 10,
mentre il serv.-client inizierà con 20. Al terzo e quarto byte troveremo
quel che è un valore short che però non è in little-endian
(cioè al contrario, la modalità usata dai programmatori esperti)
come ci aspetterem- mo. Questo contatore indica il numero di pacchetti inviati
dal server al client; ce ne sarà anche uno nei pacchetti in- viati dal
client al server. Il quinto ed il sesto byte indi- cano anche qui un valore
short non in little-endian che in- dica la lunghezza del messaggio fino alla
fine (cominciando dalla fine del valore). Ci sono poi due bytes hex e cioè
00 02 seguiti dalla lunghezza della chiave (sempre valori short) seguiti infine
dalla chiave, che noi dovremo azzerare. Per fare ciò dovremo creare il
server e fargli inviare come chia- ve 00 00 00 00 00 00 00 00. Fatto questo
il client ci invierà i dati riferiti al login (inutili qui e poi vedremo
perchè). Il pacchetto inizia con 10 0F, una stringa che sarà sempre
u- guale nelle stringhe inviate dal client. Vi è poi il contato- re in
short, i bytes alla fine del pacchetto sempre in short poi due bytes hex 10
01 che ci permetteranno di capire di che comando si tratta. Continuando, ci
sono poi i bytes 00 01 che io ho collegato al fatto che si tratti di un solo
username, ma non ne vedo lo scopo. Vi è poi un secondo valore che indi-
ca i bytes alla fine del pacchetto, sempre in short. Ora c'è la lunghezza
dello username in singolo byte, seguito dallo username. Alla fine di questo
c'è la lunghezza della pass co- dificata (e della quale per ora non conosco
ancora l'algorit- mo di decodifica). C'è poi la lunghezza della 'verifica'
se- guita dalla verifica. La 'verifica' credo sia un combinamento di pass e
user dato che cambia sia cambiando l'uno che l'al- tro. Il pacchetto finisce
con i bytes 01 0A 7F 00 00 01 00 14 A questo il server risponde, sia se è
corretto o no, inviando dei bytes nei quali comanda il client di collegarsi
ad un al- tro server. Ciò è probabilmente fatto per evitare problemi
di sovraffollamento. Questo redirecting funziona così: Inizia con i bytes
20 02, poi il valore del contatore sempre in short. Segue la lunghezza del pacchetto
fino alla fine in short. Ora il server ci comunica l'ip e la porta alla quale
dobbiamo collegarci. Il formato dell'ip sarà ABCD da noi in- terpretabile
come A.B.C.D, seguito da due bytes 00 seguiti da altri 2 bytes che definiscono
la porta in short. Essendo particolarmente intricato, faccio uno schema:
20 12 [CONTAT] [LUNGH FINE] 00 02 [LUNGH FINE] [CHIAVE]
Dove CONTAT è il contatore LUNGH FINE la lunghezza fino al- la fine del pacchetto e la chiave la chiave di codifica. Il pacchetto mandato dal client è:
10 0F [CONTAT] [LEN FINE] 10 01 00 01 [LEN FINE] [LEN USER] -> [USER] [LEN PASS] [PASS] [LEN VERIF] [VERIF]
Dove LEN FINE è la lunghezza alla fine, LEN USER è la lun- ghezza dello username, PASS è la password in codifica e VERIF è la verifica. Il server replica con:
20 02 [CONTAT] [LEN FINE] [IP] 00 00 [PORTA]
Dove IP è scritto in valori del tipo ABCD e significano A.B.C.D e PORTA è scritto in short.
Una volta fatto ciò, il client si scollega dal server e si ricollega all'indirizzo indicatogli dal server. Qui troverà un altro server c6 che funzionerà come il primo per quanto riguarda i primi due pacchetti. Poi se il login è errato in- vierà questo pacchetto: 20 03 00 02 00 00 Facilmente è possibile intuire che 20 è l'ID del server che contrassegna ogni suo messaggio, 03 è il comando di errore, i seguenti due bytes sono in contatore e 00 00 sono bytes di riempimento (almeno credo :P )
Nel caso in cui è corretto il server manda del codice, ancora in fase di analisi, in cui scrive il messaggio di benvenuto che compare in alto a destra sulla finestra di c6 e invia i banners che il client mostrerà.
A questo punto il client richiede alcune informazioni sui pulsanti, come ad esempio 'scarica l'agenda!'. Il codice per la richiesta è 10 0F 00 02 00 08 10 0D 00 02 00 02 01 2A Ancora possiamo notare i primi due bytes, sempre uguali, il contatore, la lunghezza alla fine in short, 10 0D che è il cosiddetto ID del comando e vari altri bytes che non mi sono soffermato ad interpretare (tanto la stringa di richiesta è sempre uguale!).
Il server risponde quindi con la srtinga (in schema): 20 15 [CONTAT] [LEN FINE] [NUM PULS] [LUNGH TESTO] [TESTO] -> [LUNGH LINK] [LINK] [...]
Oltre ai soliti bytes, troviamo num puls, un valore short che indica al client il numero di pulsanti da inserire; abbiamo poi TESTO che è il testo del pulsante e poi LINK che è il link a cui punta quel pulsante. Nel caso in cui sia più di un pulsante, la sequenza si ripete, partendo da lungh testo fino a link, fino all'esaurimento dei pulsanti (e di noi ihhiih :)
Il client poi invia la sua userlist al server che man mano gli dirà gli utenti che si collegano e si scollegano. Inoltre dopo aver mandato questa list, il server ci dirà i nick col- legati. La stringa di richiesta è questa (sempre schema):
10 0F [CONT] [LEN FINE LISTA] 10 03 00 03 [LEN FINE LISTA] -> [NUM NICK] [LEN NICK] [NICK] [...] 10 0F 00 04 00 07 10 -> 0A 00 04 00 01 64
Dove LEN FINE LISTA è la lunghezza fino alla fine della lis- ta (non del pacchetto), NUM NICK è il numero di nick, NICK è un nick. Il numero di nick è in short. Vengono inviati tante volte LEN NICK e NICK quanti sono i nick. Alla fine il pacchetto termina con quei bytes sopra scritti.
Una volta richiesta la lista dei nick collegati, il server ci risponderà con quelli attualmente collegati; il pacchetto è questo: 20 06 [CONTAT] [LEN FINE] [NUM NICK] [LEN NICK] [NICK]
NUM NICK è ancora una volta il numero di nick scritti, in short. LEN NICK e NICK vengono scritti tante volte quanti so- no i nick da inviare.
Può capitare che a volte all'avvio di c6 (qui si conclude il login!) venga inviato anche il pacchetto che ci definisce di- sponibili, solo per i NetFriends o Occupati. I pacchetti in questione sono: 10 0F [CONT] [LEN FINE] 10 0A 00 04 00 01 [STATO] Mettendo da parte i bytes già conosciuti, abbiamo STATO che può assumere i seguenti valori: 64 -> Disponibile 68 -> Solo NetFriends 70 -> Occupato
Analizziamo l'ultimo comando che ho reversato per ora: i mes- saggi.
Nell'invio di messaggi ci sono due comandi, uno per quello online ed uno per i messaggi verso utenti offline, (email). La differenza tra i due è minima: l'incremento di un valore. Il pacchetto è così configurato: 10 0F [CONT] [LEN FINE] 10 [VAL] 00 05 [LEN FINE] [LEN SEND] -> [SEND] 00 01 [LEN TO] [TO] [LEN FINE] [MESS]
VAL è un valore che cambia, è appunto quello che dicevo prima che incrementa: 08 -> Messaggio online 09 -> Messaggio offline (email)
SEND è colui che invia il messaggio (spoof? ^^), TO è il ri- cevente e MESS è il messaggio (ma và? :) Il valore 00 01 contenuto tra SEND e LEN TO potrebbe essere il numero di persone a cui mandare il messaggio...bisognereb- be provare a vedere mettendo 02 e due nick cosa succede :)
Beh...se mandiamo il messaggio, dobbiamo certamente anche po- terlo ricevere! :)
Per quanto riguarda la ricezione, questo è lo schema di un pacchetto inviatoci dal server: 20 0F [CONT] [LEN FINE] [LEN FROM] [FROM] [LEN TO] [TO] 02 00 -> [MESS]
Qui non c'è nulla da aggiungere...tutto chiaro no?
----==[ Saluti ]==----
Un saluto a tutte le crew in cui sono che non nomino per mo- tivi di spazio. Un altro saluto a tutti coloro che hanno pro- vato a crackare C6 e non ci sono riusciti, ma comunque una mano potevano pure darmela (non ho trovato nessuno che mi aiutasse...ma ci sono riuscito anche da solo). Entro breve realizzerò un server dimostrativo in Visual Basic, utilizza- bile solo in LAN: altri usi potrebbero essere illegali. <--==
http://www.gnomixland.com/