Il blog sull'informatica

Ho acquistato un gioco originale per la mia Xbox 360 e ho deciso di fare almeno una copia di backup (nel caso in cui il DVD si rovinasse). Creo la mia ISO ma, poichè sto usando Linux, non conosco la giusta procedura per masterizzarla. Giro un pò su Google e mi rendo conto che di guide che trattano questo argomento ce ne stanno fin troppe e, come dice il mio professore di basi di dati, troppe informazioni equivalgono a nessuna informazione. Decido quindi di fare di testa mia, e finalmente dopo qualche tentativo (e qualche DVD double layer da buttare) sono riuscito nel mio intento: creare la mia copia di backup.

Ma andiamo per ordine. La prima cosa da fare, dopo aver creato la ISO, è verificare che il security sector sia stato patchato. Alcuni tool lo fanno in automatico, altri invece no, lasciando all'utente le eventuali grane che ne derivano. Ecco come patchare il security sector (mediante il file ss.bin):

dd if=/dev/zero of=blank.iso bs=2048 count=129823 && cat blank.iso ss.bin game.iso> IMAGE.000

Con questo comando stiamo semplicemente aggiungendo a game.iso il file ss.bin, creando la nostra nuova immagine (patchata), ovvero IMAGE.000.

L'applicativo che andremo ad utilizzare per masterizzare IMAGE.000 è growisofs, bisogna quindi rendere compatibile l'immagine con questo tool. Per fare ciò basta eseguire un prepatch usando un piccolo programmino scritto in Java, ovvero imgbpatch.jar. Digitiamo quindi il seguente comando:

java -jar imgbpatch.jar IMAGE.000

ed a prepatch ultimato masterizziamo la nostra immagine:

growisofs -use-the-force-luke=dao -use-the-force-luke=break:1913760 -dvd-compat -speed=2 -Z /dev/dvd=IMAGE.000

dove /dev/dvd identifica il masterizzatore.

E' sempre buona norma eseguire un integrity check sul DVD appena realizzato, in modo da riscontrare la presenza di eventuali errori. Per fare questo ci serviamo di md5sum:

dd if=IMAGE.000 bs=2048 count=3697696 | md5sum

Se tale verifica non segnala anomalie, il nostro DVD di backup è finalmente pronto.

La miniguida termina qui, a presto.

Il VTP (Virtual Trunking Protocol) è un protocollo di livello 2 proprietario Cisco, il cui scopo è quello di mantenere allineato il database in cui sono contenute le VLAN comuni a più switch. Affinchè la propagazione delle informazioni avvenga correttamente, è necessario che tutti gli switch facciano parte dello stesso dominio VTP.

Uno switch può operare in tre modalità VTP:

Server: crea, modifica e cancella le VLAN per l'intero dominio VTP e salva le informazioni relative alle LAN virtuali all'interno dell'NVRAM. E' la modalità di default per gli switch su cui viene abilitato il VTP;

Client: non può effettuare operazioni dirette sulle VLAN di dominio (ad esempio creazione o cancellazione) e non salva nell'NVRAM le informazioni inviate dal server, occupandosi esclusivamente di propagarle ai vicini;

Transparent: può eseguire il forwarding delle informazioni inviate dal server ma è caratterizzato dalla presenza di un database locale di VLAN, il quale non influenza il database di dominio.

Alcuni casi particolari di cui bisogna tener conto sono i seguenti:

1) l'aggiornamento inviato dal server ha un revision number inferiore rispetto a quello delle informazioni possedute dal client. In tal caso il client scarterà l'update proveniente dal server.

2) gli switch non riescono a mettere in sharing le loro VLAN. E' molto probabile che il nome di dominio VTP non coincida in tutti gli switch del network.

3) il pruning mode dello switch è attivo: ciò significa che lo switch non invierà traffico broadcast, multicast o unknown (ovvero verso un'indirizzo non presente all'interno della CAM) su tutti i trunk, evitando spreco di risorse e di banda.

Inoltre, poichè in un dominio VTP possono esserci più server, si potrebbe verificare uno scenario del tutto sconveniente, in cui viene aggiunto uno switch che opera in modalità server e che possiede un revision number inferiore rispetto a quello dei server già attivi. Ciò farebbe in modo che sull'intero dominio VTP tutte le VLAN precedenti vengano sovrascritte da quelle presenti nel database del server appena aggiunto. Si potrebbe evitare ciò semplicemente aggiungendo una password nell'ambito dello stesso dominio VTP.

Per ciò che concerne la configurazione di tale protocollo, alcuni comandi utili sono i seguenti (per il server):

Switch1#vlan database

configuro il nome del dominio:

Switch1(vlan)# vtp domain CCNA

dichiaro le VLAN che dovranno essere propagate agli altri switch:

Switch1(vlan)# vlan 2 name Administration
Switch1(vlan)# vlan 3 name Students

configuro la password VTP:

Switch1(vlan)# vtp password Cisco

Nell'ambito del client mi basterà digitare:

Switch2#vlan database

dichiaro espressamente che lo switch deve operare in modalità client:

Switch2(vlan)# vtp client

configuro la password VTP:

Switch1(vlan)# vtp password Cisco

ed infine configuro il nome del dominio:

Switch2(vlan)# vtp domain CCNA

Per ciò che concerne la diagnostica possiamo digitare:

Switch# sh vtp status

il cui output è simile al seguente:

VTP Version                     : 2
Configuration Revision          : 247
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 33
VTP Operating Mode              : Client
VTP Domain Name                 : Lab_Network
VTP Pruning Mode                : Enabled
VTP V2 Mode                     : Disabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x45 0x52 0xB6 0xFD 0x63 0xC8 0x49 0x80
Configuration last modified by 0.0.0.0 at 8-12-99 15:04:49

Switch# sh vtp counters

che mostra tutta una serie di statistiche associate allo scambio di pacchetti nell'ambito del protocollo in questione, ad esempio:

VTP statistics:
Summary advertisements received: 7
Subset advertisements received: 5
Request advertisements received: 0
Summary advertisements transmitted: 997
Subset advertisements transmitted: 13
Request advertisements transmitted: 3
Number of config revision errors: 0
Number of config digest errors: 0
Number of V1 summary errors: 0
VTP pruning statistics:

Trunk            Join Transmitted Join Received    Summary advts received
from on-pruning-capable device
---------------- ---------------- ---------------- ---------------------------
Fa5/8             43071            42766            5

Il post termina qui, a presto.

NB: tali comandi si riferiscono a CatOS.

Prima di iniziare è necessario fare una piccola premessa: quanto segue non è un tutorial su come aggiornare il firmware del lettore dvd della vostra xbox360, ma solo una sorta di racconto impreziosito da qualche "pillola" in gergo tecnico.

Bene, diciamo che qualche anno fa ho acquistato questa fantastica console di casa Microsoft (mi sembra fosse il 2007), per la precisione la versione arcade della stessa (ovvero il modello base, senza HD, senza uscita HDMI e con un solo pad in dotazione). Poichè una console senza giochi è completamente inutile, mi sono rifornito dei titoli più disparanti, da Assassin's Creed, passando per Halo 3 fino ad arrivare ai vari Gears of War, Ninja Gaiden, PES e FIFA. Tutto va per il verso giusto fin quando un graffio più o meno profondo rende uno di questi giochi inutilizzabile. Per fortuna che ho il mio bel backup, esclamo io... peccato però che con il firmware originale del lettore tale backup sia illegibile.

Provvedo quindi a smontare la mia xbox 360 ed a portarla in un negozio in cui si effettuano le cosiddette "modifiche". Pochi giorni e tutto è pronto, riesco a giocare finalmente sia con i giochi originali che con il mio backup.

Passano gli anni e poichè tale situazione di "stabilità" non poteva certamente durare all'infinito, iniziano a presentarsi i primi problemi. In particolare, i giochi di "ultima generazione", i cosiddetti wave3 e wave4 vengono semplicemente ingorati dal mio lettore dvd, risultando inservibili. Cosa fare quindi? La risposta è semplice: aggiornare il firmware del lettore.

Ok, per prima cosa devo identificare il tipo di lettore installato sulla mia console... apro il carrellino e mi accorgo che si tratta inequivocabilmente di un Hitachi.

Bene, allora scarico l'ultima versione del firmware iXtreme (per la precisione 1.51), scareno l'xbox 360, collego il cavo SATA alla scheda madre del mio PC ed imposto la sequenza di boot di quest'ultimo, dato che al riavvio dovrà partire il cd live di Slax 2.1 anzichè Windows XP installato sull'hard disk.

Direte voi... e cosa c'entra il cd live di Slax? Beh, semplicemente è proprio grazie a questo che il lettore dvd della xbox360 entra in modeB, ovvero in una sorta di modalità di debug che consente a Windows XP di rilevarlo come se fosse una normalissima periferica di sistema.

Quindi riavvio il PC, tolgo il cd live dal lettore ed aspetto che Windows completi la fase di boot. Adesso do un'occhiata alla gestione risorse e vedo che il mio fantastico Hitachi è elencato correttamente tra le periferiche di I/O.

Fin qui tutto liscio. Allora scarico JungleFlasher, faccio il dump del vecchio firmware (non si sa mai), ripristino il firmware di fabbrica (il cui nome file è orig78* oppure orig79*, a seconda del tipo di lettore Hitachi che avete in dotazione sulla vostra console) ed infine aggiorno tutto alla versione 1.51 di iXtreme.

A procedura completata spengo l'Xbox 360, rimonto l'involucro esterno, collego alimentazione e cavo video. Inserisco nel lettore il mio gioco nuovo fiammante e di ultima generazione, premo il pulsante di accensione... et voilà, tutto funziona alla grande.

Di seguito qualche foto a dimostrazione della mia piccola grande impresa.

A presto.

In questo post abbiamo visto qual è la logica su cui si basa il funzionamento dello standard IEEE 802.1x. Ora vedremo come configurare tale protocollo su uno switch Cisco Catalyst 3750, in modo da fargli svolgere la funzione di autenticatore.

Per prima cosa definiamo tutti i parametri necessari al protocollo in questione:

Switch3750# conf t
Switch3750(config)# aaa new-model
Switch3750(config)# aaa authentication dot1x default group radius
Switch3750(config)# ip radius source-interface fa1/0/1 (ovvero la porta a cui è allacciato il server RADIUS che funge da server di autenticazione)
Switch3750(config)# ip radius-server host <IP del server RADIUS>
Switch3750(config)# radius-server key <chiave di autenticazione per fasrsi riconoscere dal server RADIUS>
Switch3750(config)# dot1x system-auth-control (abilita lo switch a svolgere la funzione di autenticatore)

Ora, supponiamo che tutte le porte del nostro switch debbano essere configurate in modalità access e che su tutte debba essere abilitata l'autenticazione mediante dot1x. Per fare ciò occorre usare i seguenti comandi:

Switch3750(config)# interface range fa1/0/1 - 1/0/48
Switch3750(config-range)# switchport access vlan 6
Switch3750(config-range)# switchport mode access
Switch3750(config-range)# dot1x port-control auto (abilita il protocollo 802.1x su tutto il range di porte)
Switch3750(config-range)# dot1x guest-vlan 66 (tale parametro è opzionale e specifica su quale vlan deve essere "rilagato" il supplicante che ha fornito credenziali di accesso non valide per 3 volte consecutive).

Salviamo la configurazione:

Switch3750# copy run start

Ed abbiamo finito.

PS: tali comandi sono validi per IOS versione >= 12.1(14) e non per CatOS.

PPS: alcuni comandi utili alla diagnostica sono i seguenti:

Switch3750# sh dot1x
Switch3750# sh dot1x statistics

A presto.

Lo standard IEEE 802.1x, introdotto nel 2001, viene adoperato molto spesso nell’ambito delle reti wireless, ma può essere “adattato” anche alle reti wired. In particolare, tale standard riconosce 3 elementi distinti:

1. Il supplicante, ovvero la macchina che chiede di essere autenticata;
2. L’autenticatore, ovvero il dispositivo che fa da tramite tra supplicante e server di autenticazione;
3. Il server di autenticazione, il cui compito è quello di ricevere le credenziali inviate dal supplicante ed eventualmente garantirne l’accesso alla rete.

Ora, occorre precisare che il traffico generato tra l’autenticatore ed il server di autenticazione risulta cifrato. Ciò si rende necessario poiché si vuole evitare che eventuali operazioni di sniffing possano consentire ad un attaccante di ottenere credenziali valide per l’accesso al network.
Il protocollo utilizzato per l’invio delle credenziali di accesso prende il nome di EAP (Extensible Authentication Protocol), appartenente al layer 2 della pila ISO/OSI. Esso consente di utilizzare diversi metodi di autenticazione, tra cui one time password, Kerberos, certificati digitali, smartcard, ecc.
Nella fattispecie, esistono le seguenti sotto tipologie di EAP:

• EAP-TLS (Transport Layer Security): sfrutta i certificati digitali per valutare l’identità del supplicante. Ovviamente, anche sul server di autenticazione deve essere installato un certificato X.509 con finalità di autenticazione. Tale approccio presenta però un punto debole, ovvero risulta poco scalabile.
• EAP-TTLS (Tunnel Transport Layer Security): variante dell’EAP-TLS, richiede la presenza di un certificato di autenticazione solo sul server di autenticazione e si avvale di un tunnel cifrato per lo scambio delle informazioni tra supplicante e server di autenticazione stesso.
• EAP-LEAP (Lightweight Extensible Authentication Protocol): standard proprietario Cisco, veniva utilizzato nell’ambito degli AP Aironet che sfruttavano il WEP come algoritmo di cifratura. Ovviamente, essendo il WEP vulnerabile, lo è di riflesso anche lo standard in questione.
• EAP-PEAP (Protected Extensible Authentication Protocol):  sviluppato da Cisco, Microsoft ed RSA Security.

Autenticazione passo dopo passo

Appena la macchina viene allacciata allo switch (o viene accesa), la sua interfaccia di rete (NIC) invierà al commutatore un messaggio di EAP-Start, in modo da mettere in piedi una sessione tra il supplicante e l’autenticatore.
A questo punto lo switch risponderà con un EAP Request Identity, richiedendo sostanzialmente al supplicante le sue credenziali.
Successivamente, il supplicante invierà allo switch tali credenziali, le quali verranno incapsulate da quest’ultimo all’interno di un pacchetto IP ed inoltrate al server di autenticazione (solitamente di tipo RADIUS). Durante questa fase, il supplicante non ha ancora accesso al network a livello IP, ma l’unico traffico consentito è quello EAP.
Dopo che il server di autenticazione avrà valutato le credenziali di accesso inoltrategli dall’autenticatore, esso risponderà con un messaggio di Accept o Reject.
Infine, lo switch inoltrerà tale risposta al supplicante, nella forma di EAP Success o EAP Reject. Nel primo caso verrà consentito il traffico IP da e verso il supplicante, mentre nel secondo caso la porta a cui è allacciato il supplicante verrà bloccata oppure piazzata su una VLAN creata ad hoc e con accesso ristretto.

Nei prossimi post vedremo come abilitare tale protocollo sugli switch Cisco Catalyst 3750. A presto.

Prima di introdurre questa mini-guida, occorre precisare che non tutte le IOS Cisco supportano SSH. Nella fattispecie, quelle abilitate a ricevere connessioni mendiante Secure SHell riportano la dicitura K9 nell'ambito del filename.

Ma veniamo a noi. Per prima cosa, occorre creare la chiave RSA da utilizzare come fingerprint. Per fare ciò basta digitare il comando:

Switch(config)# crypto key generate rsa general-keys label ssh-fingerprint

Dopodichè digitiamo:

Switch(config)# ip ssh version 2

in modo da abilitare sul dispositivo la versione 2 del protocollo SSH (più robusta della 1).

Adesso definiamo username e password di accesso:

Switch(config)# username <vostro username> password <vostra password>

A questo punto disabilitiamo l'accesso telnet e consentiamo solo quello ssh usando il comando transport input (e già che ci siamo aggiungiamo username e password appena creati come credenziali per il login):

Switch(config)# line vty 0 15
Switch(config)# login local
Switch(config-line)# transport input ssh
Switch(config-line)# end

Infine salviamo la configurazione:

Switch# copy run start

ed il gioco è fatto.

A presto.

In questi giorni stiamo assistendo ad un tam tam mediatico riguardante l'hacker Julian Assange ed il portale da lui fondato, ovvero Wikileaks. Notate bene che ho utilizzato il termine hacker e non cracker. Direte voi: "bhè, non c'è grande differenza tra i due termini, fondamentalmente sono dei sinomini". E qui vi sbagliate (e di grosso anche).

Punto primo: l'hacker è colui che è spinto dalla curiosità, da una voglia insaziabile di conoscenza, dalla voltontà di sperimentare tecniche nuove, siano esse attribuibili all'informatica in senso stretto, oppure ad una qualunque altra disciplina (dall'elettronica fino alla semplice meccanica). Non è un caso, infatti, che i primi hacker (i famosissimi membri del Tech Model Railroad Club del MIT) si dedicassero alle attività più disparate, che andavano dall'esplorazione dei cunicoli della metro, fino alla mappatura delle linee telefoniche ed ai primi tentativi di programmazione (su macchine quali il PDP-1, PDP-6, PDP-10 et similia).

Ora, un'altra caratteristica peculiare degli hacker (secondo me) è quella di condividere le proprie conoscenze e le proprie esperienze. Ovviamente tale condivisione deve essere sempre e comunque dettata e regolata dal buon senso. Quindi, non stupitevi se gli hacker tendono ad essere molto schivi e diffidenti... ciò è normalissimo in quanto molto spesso commettono atti illeciti (ad esempio intrusioni sui sistemi informatici altrui), perseguibili in termini di legge in quasi tutti i Paesi del mondo. Per questa ragione, molti hacker condividono le proprie conoscenze solo ed esclusivamente con altri hacker, poichè tra loro vige un rapporto basato sulla fiducia e sulla stima reciproca. Fiducia spesso ripagata dalla solidarietà manifestata da ciascuno di essi nei confronti di altri hacker che se la "passano male" (poichè, ad esempio, sono braccati dalla polizia), nonostante ciò significhi una probabile incriminazione per favoreggiamento.

Ma non è tutto. Gli hacker "navigati" spesso e volentieri accolgono sotto la loro ala protettrice un giovane di belle speranze, il quale verrà istruito a dovere non tanto dal punto di vista tecnico quanto dal punto di vista etico: gli verrà mostrato quali sono i valori che spingono gli hacker a comportarsi in un determinato modo, qual è la loro tara mentale e perchè la conoscenza e la curiosità rivestono un ruolo così importante.

Ora, però, occorre fare un po' di chiarezza: non tutti gli hacker sono buoni e irreprensibili dal punto di vista morale ed etico. Solitamente i grandi guru della sicurezza informatica tendono a distinguerli in tre grandi categorie: white hat, grey hat e black hat. Fanno parte della prima categoria coloro che "scandagliano" la rete alla ricerca di sistemi vulnerabili, per poi avvisare l'amministratore del sistema e dare man forte alla messa in sicurezza dell'elaboratore. I black hat sono coloro che bucano i sistemi altrui con scopi eticamente sindacabili (il termine carding vi dice qualcosa?). Infine vi sono i grey hat, ovvero gli hacker borderline, che non possono essere schierati nè tra i "buoni", nè tra i "cattivi". Personalmente credo che ogni hacker sia una storia a se stante e che ogni tentativo di schematizzazione degli stessi sia del tutto inutile.

Punto secondo: il cracker è colui che è spinto solo ed esclusivamente dalla voglia di distruggere tutto ciò che incontra lungo il proprio cammino. Ne sono un esempio gli script kiddie, che utilizzano "strumenti" già esistenti per colpire ed affondare. Sono spinti solo dalla voglia di notorietà (non è raro che si vantino di questo e di quell'"hack") ed agiscono in modo poco intelligente: attraverso determinati tool effettuanto uno scanning su intere classi di indirizzi IP fino ad individuarne alcuni vulnerabili agli exploit preconfezionati di cui si avvalgono sistematicamente. Non per niente sono le vittime preferite dei cosiddetti honeypot.

A differenza dei cracker, un hacker non usa quasi mai tool preconfezionati, ma è solito creare una propria cassetta degli attrezzi costituita da exploit e programmi vari messi a punto direttamente da lui.

Ma torniamo a Julian Assange. Secondo me si è candidato ad essere uno dei più famosi hacker della storia (se non addirittura il più famoso), superando di gran lunga il celeberrimo Kevin D. Mitnick, pioniere dell'ingegneria sociale e di tecniche rivoluzionarie quali l'IP spoofing (Shimomura ne sa qualcosa). Il suo punto di forza è proprio la curiosità e la volontà di diffondere la "conoscenza", ripudiando tutte quelle istituzioni che, per principio o per necessità, vogliono porre un veto al libero scambio di informazioni. Ma dirò di più: sinceramente non conosco le vicende per le quali lo stesso Assange è stato condannato, magari è colpevole, magari non lo è affatto. So solo che questa incriminazione e la successiva condanna coincidono "casualmente" con la diffusione on-line del materiale "sensibile" proveniente dalle ambasciate americane di tutto il mondo. E definire attacchi "hacker" i maldestri tentativi DDoS perpetrati contro il sito di Wikileaks mi sembra una vera boiata. Gli attacchi DDoS non sono MAI opera di hacker, ma di cracker, oppure di cyber warrior (ovvero di gente addrestata alla guerriglia digitale, che usa come arma il proprio pc e come munizioni i pacchetti instradati mediante collegamenti a banda larga).

Se poi, un giorno, PayPal decide di bloccare il conto su cui Wikileaks riceve le donazioni e se gli hosting provider rifiutano sistematicamente di ospitare il portale di Assange, vuol dire che alcune potenze riescono ancora ad imporre il proprio volere indisturbatamente. Ciò potrà accadere nel mondo reale, ma non in quello virtuale, poichè LIBERO PER DEFINIZIONE. Proprio per questo motivo, Wikileaks dovrà continuare ad esistere, poichè la conoscenza è sacra ed è un diritto innegabile... per ciascuno di noi.

Da buon (presunto) sistemista Unix, disconosco (in parte) i server Microsoft. Però, recentemente ho avuto a che fare con un DC (Domain Controller) basato su Active Directory, che svolge (ovviamente) anche funzioni di DNS. Ora, da una rapida occhiata ai record, ho notato la presenza di diverse entry duplicate. Dove sta l'intoppo? Semplice, sta nel cosiddetto scavenging, ovvero un parametro che specifica ogni quanto verranno effettuate della scansioni automatiche sui record DNS alla ricerca di eventuali duplicati (per rimuovere le entry scadute, soprattutto nel caso in cui i stia usando un server DHCP). Basta quindi abilitare tale funzionalità (e settarla a dovere) per risolvere questo problema.

See ya.

Premesso che avere a che fare con gli AP Aironet di casa Cisco non è uno scherzo, questa guida ha come scopo quello di consentire un'installazione della IOS nel caso in cui l'immagine di default presente nella flash sia corrotta oppure sia stata cancellata per sbaglio.

Una volta conclusa la fase di bootstrap del nostro AP, poichè non ha a disposizione una IOS "commestibile", esso entrerà automaticamente in recovery mode, il cui prompt è il seguente:

ap:

Per prima cosa dobbiamo definire indirizzo IP e subnet mask da assegnalre all'access point, poichè l'IOS dovra essere caricata su di esso mediante server TFTP. Possiamo settare l'IP e la mask attraverso i comandi:

ap: set IP_ADDR <indirizzo IP>

ap: set NETMASK <mask>

Adesso abilitiamo l'access point alla ricezione dei dati mediante TFTP:

ap: tftp_init

Lanciamo una sessione TFTP per scaricare la IOS (in formato *.tar) direttamente sulla flash dell'AIRONET:

ap: tar -xtract tftp://192.168.1.2/images/c350-k9w7-tar.122-13.JA1 flash:

In realtà, tale comando consente anche l'estrazione della IOS man mano che viene scaricata dal server TFTP.

Diciamo all'AP quale immagine deve utilizzare durante la sequenza di boot:

ap: set BOOT flash:/c350-k9w7-mx.122-13.JA1/c350-k9w7-mx.122-13.JA1

Controlliamo che tutti i parametri fin'ora definiti siano stati carpiti correttamente dall'access point:

ap: set

il cui output dovrebbe essere simile al seguente:

BOOT=flash:/c350-k9w7-mx.122-13.JA1/c350-k9w7-mx.122-13.JA1
IP_ADDR=192.168.1.2
NETMASK=255.255.255.0

Infine, lanciamo il comando:

ap: boot

Dopo aver avviato l'IOS appena installata, diciamo all'AP quale immagine deve utilizzare digitando:

ap(config)# boot system flash:<immagine ios>

Facciamo un copy run start per salvare le nuove impostazioni ed abbiamo finito.

A presto.