Il ThinkPad rinasce biometrico

IBM ha integrato per la prima volta su di un notebook un sensore di impronte che consente di effettuare l'autenticazione biometrica al sistema e ad applicazioni e servizi compatibili

Research Triangle Park (USA) – Con una mossa che potrebbe spingere le tecnologie di autenticazione biometrica verso un più grande bacino di utenti, IBM ha introdotto un nuovo modello di notebook, il ThinkPad T42, che integra uno scanner di impronte.

Il dispositivo biometrico è solo il componente più in vista di un sistema di sicurezza hardware e software il cui compito è quello di proteggere l’accesso al sistema e alle informazioni che contiene. Fra i componenti di tale sistema vi è un chip che si occupa di cifrare i dati e un programma, chiamato Client Security Software 5.4, utilizzabile dall’utente per gestire le proprie password e i propri login biometrici.

Lo scanner di impronte del ThinkPad T42 Il lettore di impronte incluso nello chassis del T42 è di tipo swipe-scanner: a differenza dei tradizionali scanner “a tocco”, dove per autenticarsi è sufficiente appoggiare per pochi secondi il dito al sensore, negli swipe-scanner l’autenticazione avviene trascinando la punta del dito lungo il sensore. Questo, secondo IBM, consente di analizzare una più ampia porzione dell’impronta digitale e, nello stesso tempo, rendere assai più difficoltosa la possibilità di ingannare il lettore attraverso impronte false. L’altro vantaggio che caratterizza questo tipo di scanner sono le sue dimensioni, assai più compatte di quelle di un lettore d’impronte tradizionale.

IBM ha spiegato che il sistema di sicurezza integrato nel suo nuovo notebook, l’Embedded Security Subsystem, può essere sfruttato dagli utenti aziendali per autenticarsi anche in altre risorse, come siti Internet, intranet, VPN e servizi on-line. Ovviamente, perché la cosa funzioni, tali risorse devono supportare questo tipo di identificazione.

Il ThinkPad T42, di cui è possibile apprendere maggiori dettagli qui , verrà commercializzato il 19 ottobre a partire da un prezzo di 1.699 dollari.

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Parliamone scrive:
    Non capisco...
    Perché molti definiscano come Inutile questa feature (Che, tra l'altro, è presente in diversi processori architetturalmente più evoluti degli X86, che come sappiamo tutti sono, per problemi di legacy, dei papocchi immani).Ovvio, si possono utilizzare sistemi software (Stackguard, Propolice e i vari "canarini", implementati se non sbaglio soprattutto in OpenBSD) per evitare di "debordare" da un bufferQuesto risolve il problema di Buffer Overflow, ma non dell'eventuale eseguibilità dello stack: se lo stack è sufficientemente grande, è possibile scrivere nello stack del codice malevolo e poi mandarlo in esecuzione, in un modo o nell'altro. Con questo tipo di protezione, invece è comunque possibile scrivere codice malevolo nello Stack ma appena si prova a mandarlo in esecuzione, il Processore si rifiuterà di farlo, perché la pagina di memoria che contiene lo stack sarà stata precedentemente marcata come "Non eseguibile".Tutto qui.==================================Modificato dall'autore il 05/10/2004 11.30.04
    • Giambo scrive:
      Re: Non capisco...
      - Scritto da: Parliamone
      Perché molti definiscano come Inutile
      questa featureNon e' propriamente inutile, pero' lascia un pochino perplessi il fatto che per arginare il fenomeno di "cattivi programmatori" si debba ricorrere a trucchi ad un livello piu' basso.Mi viene in mente quel tale che, comperata l'auto nuova, sfrecciava come un disgraziato per la citta', sicuro del suo airbag e delle barre laterali :)Personalemnte la trovo una feature interessante, non indispensabile pero'. Anche perche' ultimamente si tende a "virtualizzare" il contesto nel quale gira l'applicazione (JVM, per esempio), parando il culo a molti cattivi programmatori a livello piu' alto :-)
      • avvelenato scrive:
        Re: Non capisco...
        - Scritto da: Giambo

        - Scritto da: Parliamone


        Perché molti definiscano come
        Inutile

        questa feature

        Non e' propriamente inutile, pero' lascia un
        pochino perplessi il fatto che per arginare
        il fenomeno di "cattivi programmatori" si
        debba ricorrere a trucchi ad un livello piu'
        basso.
        Mi viene in mente quel tale che, comperata
        l'auto nuova, sfrecciava come un disgraziato
        per la citta', sicuro del suo airbag e delle
        barre laterali :)

        Personalemnte la trovo una feature
        interessante, non indispensabile pero'.
        Anche perche' ultimamente si tende a
        "virtualizzare" il contesto nel quale gira
        l'applicazione (JVM, per esempio), parando
        il culo a molti cattivi programmatori a
        livello piu' alto :)

        ricorda, non stiamo parlando di incompetenze in programmazione, ma di codice malevolo, e questo, se c'è l'interesse, può esser scritto per qualsiasi SO (e ora venite pure a dirmi che Linux è sicuro e non lo cracca nessuno e anche se lo cracca non può far danni che così mi faccio Cuattro Crasse Risate)
        • Giambo scrive:
          Re: Non capisco...
          - Scritto da: avvelenato
          ricorda, non stiamo parlando di incompetenze
          in programmazione, ma di codice malevolo,Non proprio, si sta' parlando di "programmatori" che, non checkando i buffers, permettono di riscrivere aree di memoria riservate ad altro con codice malevolo.Contro il codice malevolo (Trojan, spyware, ...) l'unica arma e' avere il sorgente del programma che stai per installare :)
  • Anonimo scrive:
    direi......
    ......evviva!!!:):D
  • Anonimo scrive:
    IMPARARE A PROGRAMMARE no, eh?
    po*ca pu77ana, dimenticarsi di controllare i puntatori ai buffer è il primo errore che si fa il primo giorno che si comincia a programmare in C, nonostante ciò adesso invece di svegliarsi e di imparare a programmare come si deve, occorre implementare in hardware qualcosa che previene i bachi software, ribaltando così la gerarchia chi-controlla-cosa... Insomma ne ho conosciuti di programmatori impediti che non si rendevano minimamente conto di cosa significa prevedere le condizioni d'errore, neppure in programmi semplicissimi, ma non credevo chela situazione fosse così grave!bye
    • The Raptus scrive:
      Re: IMPARARE A PROGRAMMARE no, eh?
      ... Scusa ma non ho capito:Se io nell'area dati (esempio: faccio un malloc, parlimo in C dunque!) e ci scrivo dati qualunque è tutto OK.Se poi faccioun salto a quell'area il sistema operativo NON dovrebbe lasciarmelo fare. Non vorrei uscire fuori campo, ma potrebbe solo farlo con le istruzioni privilegiate in modalità supervisore. Ma lasciamo perdere.).Quindi è un problema di S.O., NON tanto di microcodice del sistema!Adesso che questo si possa fare indiscriminatamente è senz'altro sbagliato. Mi sembra incredibile che una simile stupidata non venisse controllata prima. Ma visto che neppure Linux permetteva di farlo (solo im modalità superuser forse? boh!!).Ora se un programma generico (= qualunque) NON controlla i puntatori, beh, neppure io l'ho mai fatto, e non vedo perchè dovrei. Semplicemente se alloco memoria mi preoccupo che questa mi venga data dal S.O. e basta, poi ci metto quello che mi pare. Onestamente non ho MAI fatto caso a cosa sucedeva SE saltavo ad eseguire in quella zona. Posso però dirti che se sbagliavo un puntatore (eh, non è così difficile ... !) il sistema crashava, senza dirmi perchè o dove,Con appositi tools mi accorgevo di questo (NuMega, se nn mi sbaglio), e magari mi diceva anche dove. Altrimenti erano proverbiali C...I!Se io permetto ad un driver per esempio (che gira nel kernel) di allocare memoria oppure con un buffer owerflow (oppure Integer out of range esempio!), penso che il S.O. non controlli pper questioni di priorità e velocità.Corretto?Ciao
      • Anonimo scrive:
        molto + semplice
        Mi riferivo a svarioni molto più banali: esempio tipico, il sedicente programmatore deve ricevere una stringa lunga x dalla seriale, allora alloca un buffer di dimensione x+1 (per lo zero finale, perchè i sedicente programmatore è diligente!), poi scrive una bellissima routine che aspetta i caratteri dalla seriale e li mette uno per uno nel buffer fino a che arriva il carriage return (o il carattere eof a seconda delle preferenze) e alla fine aggiunge il terminatore - zero finale. Il "buffer" non è altro che un vettore di caratteri e il "puntatore" è semplicemente l'indice usato per puntare ai caratteri del buffer... più semplice di così!?!?!?!?Durante le prove, tutto bene.Appena installato dal cliente... un disastro. Basta che il sistema remoto mandi stringhe diverse (più lunghe) da quelle previste, ecco il buffer overflow! Oppure basta che restino dei caratteri spurii nei buffer di ricezione gestiti dal sistema operativo... e il buffer lungo x+1 allocato dal nostro bravo programmatore va subito in overflow. Allora lui comincia a dare la colpa ai disturbi, all'hardware instabile, ai cavi... Poi come al solito si dimostra dove stava l'errore, ma pochi capiscono la gravità di un simile modo di programmare... Così il Bravo Programmatore non viene cacciato via a calci nel sedere. Anzi, molti saranno ancora portati a credere che i problemi erano dovuti all'hardware instabile ecc. ecc.
      • Anonimo scrive:
        Re: IMPARARE A PROGRAMMARE no, eh?

        Corretto?Per evitare un BOF devi controllare non tanto che i puntatori siano usati correttamente, ma che non venga scritto + di quanto il buffer associato al puntatore possa contenere.Di solito questo avviene quando scrivi direttamente nel buffer dell'input dell'utente senza prima controllarne la lunghezza.Ad esempio, più che controllare i puntatori devi controllare di non usare certe funzioni (tipo get) direttamente su un array di char ... E' facile che qualche volta te ne scappi qualcuno, e su un programma notevolmente complesso ben venga il NX ...
    • Anonimo scrive:
      Re: IMPARARE A PROGRAMMARE no, eh?
      sborone che c...o c'entra saper programmare o menoforse per te, quando ti si blocca il pc mentre smanetti coi tuoi programmini in c, eviti di riavviare
      • Anonimo scrive:
        Re: IMPARARE A PROGRAMMARE no, eh?
        - Scritto da: Anonimo
        sborone che c...o c'entra saper programmare
        o meno
        forse per te, quando ti si blocca il pc
        mentre smanetti coi tuoi programmini in c,
        eviti di riavviareMa una volta questo non era punto informatico?
    • Anonimo scrive:
      Re: IMPARARE A PROGRAMMARE no, eh?
      Ma se si risolve il problema a monte non è meglio comunque?Esistono per lo stesso motivo i linguaggi ad alto livello: per non reinventare l'acqua calda!
      • Anonimo scrive:
        Re: IMPARARE A PROGRAMMARE no, eh?
        - Scritto da: Anonimo
        Ma se si risolve il problema a monte non
        è meglio comunque?

        Esistono per lo stesso motivo i linguaggi ad
        alto livello: per non reinventare l'acqua
        calda!Tu saresti in grado di scrivere un codice di migliaia di righe (per non parlare di un sistema operativo) completamente esente da bug? Se ci riesci, ti candido personalmente al premio Nobel (a patto di non riempire il codice di nop 's).
    • Anonimo scrive:
      Re: IMPARARE A PROGRAMMARE no, eh?
      non credo abbiate capito il problemac'è chi fa il BOF volontariamenteper mettere in memoria il suo bel worm come se fosse un'immagine o una file audioquello che cercano di fare è impedire ai virus writer di sfruttare il BOF in futuroALK
  • Anonimo scrive:
    A ME NON FUNGE!
    Il service pack due a me non funziona!Le propietà di rete/connessioni .. spariscono!Non si avviano i processi il computer va in tilt ... hehehehe il tipo ha paura senza sp2 .. io no! :-)
    • Anonimo scrive:
      Re: A ME NON FUNGE!
      - Scritto da: Anonimo
      Il service pack due a me non funziona!Se a te non funziona e ad altri milioni si... mmmm... direi che forse il problema e' "tuo" non loro. :)
      • Anonimo scrive:
        Re: A ME NON FUNGE!

        Se a te non funziona e ad altri milioni
        si... mmmm... direi che forse il problema e'
        "tuo" non loro. :)Mmmm... se con alcuni bios non funziona...se con numerosi software non funziona...se (stime M$) su 10 installazioni 3 vanno a farsi benedire (certo, se hai 100 macchine gemelle che ricadono nell'altro 70% dei casi e installi una *unica* immagine funzionante non hai problemi)...mi sa che i poblemi sono di un certo sig. Cancelli!
  • Anonimo scrive:
    A livello di codice
    Mi interesserebbe sapere se questa "limitazione" hardware influenzera' anche la possibilita' di "modificare" un codice iniettandolo con le proprie routine. Io per hobby creo "mods" per giochi e spesso mi capita di dover modificare aree di memoria-codice sostituendo appunto parti di routine con le mie, oppure chiamando pezzi di codice scritti da me che risiedono nella memoria a disposizione dell'utente (proprio come dice l'articolo). Non e' un buffer overflow, ma il principio di funzionamento e' il medesimo... leggendo l'articolo pare che questo non sara' piu' possibile, be' spero di no, moddare i giochi e' la mia passione. :(
    • Anonimo scrive:
      Re: A livello di codice
      se utilizzato mentre il codice non è in esecuzione funziona (quindi crakkatori, non temete). Creare tuttavia software che modifica il codice di un applicativo di esecuzione in runtime allora sei fregato amico. E' vero, per alcune cose è limitativo, come forse nel tuo caso (non ho capito, realizzi tipo trainer per i giochi?), ma credo che in realtà i mod li prepari prima che il programma parta quindi non dovresti avere problemi
      • Anonimo scrive:
        Re: A livello di codice
        Creo mod, non trainer o cheat per scelta "etica" :) (anche se il principio di funzionamente e' identico) ...odio i cheater.In pratica "inserisco" nel gioco funzioni non implementate nella versione originale (le "mancanze" che riscontrano i giocatori) oppure "correggo" errori, in pratica mini-patch, della cui realizzazione dovrebbe curarsi la casa, le faccio io (cosi' come molte altre persone) per passione.Ovviamente non posso intervenire sul sorgente, quindi devo necessariamente "patchare" l'eseguibile, e purtroppo nei giochi "moderni" questo non e' possibile intervenendo sull'eseguibile sul disco ma devo farlo in memoria, perche'? Perche' le nuove protezioni anticopia sono prese da un film di spionaggio :D ...almeno oggi patchare un eseguibile protetto ad esempio con starforce3 (ultima versione) e' una impresa impossibile non disponendo del sorgente originale, visto che gran parte dello stesso e' cryptato (viene decryptato in memoria).In poche parole sono fotutto (almeno amatorialmente). :(
        • avvelenato scrive:
          Re: A livello di codice
          - Scritto da: Anonimo
          Creo mod, non trainer o cheat per scelta
          "etica" :) (anche se il principio di
          funzionamente e' identico) ...odio i
          cheater.
          In pratica "inserisco" nel gioco funzioni
          non implementate nella versione originale
          (le "mancanze" che riscontrano i giocatori)
          oppure "correggo" errori, in pratica
          mini-patch, della cui realizzazione dovrebbe
          curarsi la casa, le faccio io (cosi' come
          molte altre persone) per passione.
          Ovviamente non posso intervenire sul
          sorgente, quindi devo necessariamente
          "patchare" l'eseguibile, e purtroppo nei
          giochi "moderni" questo non e' possibile
          intervenendo sull'eseguibile sul disco ma
          devo farlo in memoria, perche'? Perche' le
          nuove protezioni anticopia sono prese da un
          film di spionaggio :D ...almeno oggi
          patchare un eseguibile protetto ad esempio
          con starforce3 (ultima versione) e' una
          impresa impossibile non disponendo del
          sorgente originale, visto che gran parte
          dello stesso e' cryptato (viene decryptato
          in memoria).
          In poche parole sono fotutto (almeno
          amatorialmente). :(se viene decrittato in memoria ci dev'essere una parte di codice dedicata alle routines di decrittaggio, e da qualche parte una chiave. come si dice in questi casi? Ravana, ravana! :D
          • Anonimo scrive:
            Re: A livello di codice
            - Scritto da: avvelenato

            se viene decrittato in memoria ci dev'essere
            una parte di codice dedicata alle routines
            di decrittaggio, e da qualche parte una
            chiave.


            come si dice in questi casi? Ravana, ravana!
            :DHo parlato di criptazione, restando sul generico... vai a leggerti un po' di documentazione sulla Starforce3 e vedi di che si tratta. Io "ravenerei" pure, ma non saprei da dove cominciare e probabilmente morirei di vecchiaia.E' l'unica protezione attualmente in circolazione (da circa sei mesi) che e' rimasta ancora inviolata, nel senso che ci stanno lavorando (ovviamente) tutte le crew piu' quotate. L'unico modo per "aggirarla" e' ricostruire ogni porzione di file (non solo il main code) dove e' stata "iniettata" la protezione, questo significa "riscrivere" diversi MB di software... ad esempio al momento per copiare un gioco sf3 (copiarlo e farlo funzionare) servono crack da decine di megabyte (piu' software criptato c'e' dentro piu' sara' grande la patch) e una competenza fuori dal comune.Vedi ad esempio se riesci a trovare una "semplice" no-cd patch per Race Driver 2 (per PC), per non dire una versione pirata, non esiste... figuriamoci quindi se io sarei in grado di fare una cosa del genere, per i miei mod, mi gira la testa al solo pensiero. ;)
  • Anonimo scrive:
    Però è davvero un passo verso palladium!
    E' vero che proteggersi dai buffer overflow in hardware non fa mai male, però non dimenticatevi che è anche il modo più tipico di craccare un sistema protetto (per esempio xbox linux riuscì a fare il boot di una applicazione senza modchip sfruttando un buffer overflow in un programma "registrato").La microsoft ha cominciato un paio di anni fa con l'incalzare di palladium, dicendo che certificare le applicazioni è l'unico modo di renderle sicure (quando invece poi con un buffer overflow è proprio grazie alla cattiva certificazione che le fotti), ora deve ovviamente proteggersi da questo banale tipo di exploit.SELinux funziona senza il supporto hardware e fa le stesse cose, segno che non c'è bisogno del supporto in hardware (tant'è vero che anche linux fa da tempo la stessa cosa di palladium grazie ai permessi di esecuzione sui file, però basta un semplice comando per decidere chi esegue cosa, non c'è bisogno di dissaldare un chip) .
    • Anonimo scrive:
      Re: Però è davvero un passo verso pallad
      Mah, sono discorsi che lasciano il tempo che trovano. Proteggersi dal buffer overflow è sempre e comunque un bene, e non ha nulla a che vedere con la blindatura palladium. I buffer overflow esistono anche sotto linux, non sono una prerogativa di windows, ed un supporto hardware decente per eliminare questo tipo di problematiche fa solo che bene.
  • Anonimo scrive:
    Si, ma...
    Se uno fa un SO che non lo sfrutta?
    • avvelenato scrive:
      Re: Si, ma...
      - Scritto da: Anonimo
      Se uno fa un SO che non lo sfrutta?non fa nulla. non lo sfrutti, e bona lì.tanto un sacco di eseguibili sono compilati per p2... o anche peggio.... così quando va bene esegui un programma come se avessi un pentium 2 a 3,2ghz :D==================================Modificato dall'autore il 05/10/2004 0.40.13
      • The Raptus scrive:
        Re: Si, ma...
        .. MA non deve essere il S.O. che lo sfrutta? Insomma, prova a leggere il mio commento più sotto ...é il S.O. che non mi deve lasciare eseguire un salto nell'area dati. MAI !! qundo non è un virus crasha!.. oppure sono io che canno qualcosa ... boh!
        • avvelenato scrive:
          Re: Si, ma...
          - Scritto da: The Raptus
          .. MA non deve essere il S.O. che lo
          sfrutta? Insomma, prova a leggere il mio
          commento più sotto ...
          é il S.O. che non mi deve lasciare
          eseguire un salto nell'area dati. MAI !!
          qundo non è un virus crasha!

          .. oppure sono io che canno qualcosa ...
          boh!sì.esattamente canni il fatto che il codice malevolo può far fare al SO cose che normalmente il SO non farebbe.Se il SO si limita invece a delineare lo stack dati e lo stack codice, attivando l'nx è la cpu stessa che si rifiuta di eseguire istruzioni malevoli presenti nello stack dati.
  • Anonimo scrive:
    Hai voglia a mettere i 64bit....
    Ne hanno da lavorare i tecnici Intel per mettersi alla pari con gli Athlon 64 di AMD, non bastano i 64 bit o altre features presenti da tempo nelle cpu Athlon 64.Tra l'altro le estenzioni a 64bit di Intel sono più lente di quelle di AMD, parola della stessa microsoft, fatevi una ricerchina su google. Alla Intel sono anche riusciti nell'impresa di produrre una cpu ( il P4 prescott) che ha consumi e temperature allucinanti e inoltre prestazioni inferiori clock per clock con la precedente generazione di P4 (i Northwood).La scusa per le temperature troppo elevate sarebbero gli 0.09 micron che non permetterebbero, come è sempre stato finora nei vari miglioramenti del processo produttivo, una riduzione dei consumi rispetto alla tecnologia precedente per non si sa quali motivi.Dico scusa perchè a quanto pare alla piccola AMD ci sono riusciti 8) I loro Athlon 64 a 0.09 micron consumano meno ( e non poco)rispetto agli athlon 64 a 0.13 micron, e scaldano anche meno, nonostante la riduzione della superficie della cpu.Con tutto che AMD ha da tempo la migliore architettura x86, le migliori prestazioni, il miglior rapporto prezzo/prestazioni ed i più bassi consumi in rapporto alle prestazioni, oltre che molto inferiori a quelli della rivale Intel, gli Intellisti non si preoccupino, Intel venderà sempre vagonate di cpu e molte di più di AMD, potenza del marketing e della scarsa cultura informatica, e non parlo solo dell'italia.Giusto un link per supportare le mie affermazioni -
    http://techreport.com/onearticle.x/7417
    • The Raptus scrive:
      Re: Hai voglia a mettere i 64bit....
      Ottimo post!Mi sembra che il problema si sposti più sul centrino, quello si che è un micro: il P4 è puro marketing.... Anche io infatti ho un AMD ... :-)Per il 64 bit poi ...CMQ l'AMD è un cuore risc che reinterpreta il codice P4, quindi un doppio vantaggio.Mi chiedo sempre cosa farebbe un AMD alla velocità di un P4 (~4MHz?)ciao
      • Anonimo scrive:
        Re: Hai voglia a mettere i 64bit....
        - Scritto da: The Raptus
        Ottimo post!

        Mi sembra che il problema si sposti
        più sul centrino, quello si che
        è un micro: il P4 è puro
        marketing.
        ... Anche io infatti ho un AMD ... :)
        Per il 64 bit poi ...
        CMQ l'AMD è un cuore risc che
        reinterpreta il codice P4, quindi un doppio
        vantaggio.
        Mi chiedo sempre cosa farebbe un AMD alla
        velocità di un P4 (~4MHz?)

        ciaoL'architettura CRISC esiste da tempo e l'ha implementata Intel prima di AMD... Non sono veri RISC nè veri CISC, fu coniato anni fa un termine, CRISC appunto per definire il sistema ibrido con cui funzionano le attuali CPU x86...
  • Anonimo scrive:
    Alè Vai di Palladium
    Come volevasi dimostrare in un mio post di EONI fa...guardatevi "Equilibrium" giusto per avere un idea.DIVIETO DI GUARDAREDIVIETO DI PARLAREDIVIETO DI SENTIREDIVIETO DI AMAREDIVIETO DI VOLEREDIVIETO DI ESSEREed ora anche.... DIVIETO DI ESEGUIRE.Bravi robottini...tutti in fila!
    • Anonimo scrive:
      Re: Alè Vai di Palladium
      - Scritto da: Anonimo
      Come volevasi dimostrare in un mio post di
      EONI fa...guardatevi "Equilibrium" giusto
      per avere un idea.

      DIVIETO DI GUARDARE
      DIVIETO DI PARLARE
      DIVIETO DI SENTIRE
      DIVIETO DI AMARE
      DIVIETO DI VOLERE
      DIVIETO DI ESSERE

      ed ora anche.... DIVIETO DI ESEGUIRE.

      Bravi robottini...tutti in fila!Calma... NX non è palladium!
      • Anonimo scrive:
        Re: Alè Vai di Palladium
        • Anonimo scrive:
          Re: Alè Vai di Palladium
          - Scritto da: avvelenato
          l'informatica e' != a indipendence day (dove
          tra l'altro riuscivano ad infettare il
          sistema informatico di una navicella aliena,
          LOL, ma se a malapena sapevano come
          riuscissero a comunicare!!)In effetti si, e me lo sono chiesto anche io. Non sapevano che razza di sistema operativo avessero gli alieni, però gli bastava un virus per sputtanare tutto :DO forse quel virus formattava tutto e installava Windows ME ;)
    • Anonimo scrive:
      Re: Alè Vai di Palladium
Chiudi i commenti