IBM accende nuovi server Power5

Il giovane processore a 64 bit Power5 trova posto in una nuova linea di sistemi eServer attraverso cui Big Blue conta di rafforzare la propria posizione di vertice sul mercato dei server Unix/Linux


Armonk (USA) – IBM ha svelato una nuova linea di server Unix basati sul suo processore RISC di nuova generazione, il Power5, che verranno introdotti sul mercato il prossimo 27 agosto.

I nuovi server, che fanno seguito al recente lancio dei primi sistemi Power5 , rinnovano la sfida di IBM a rivali come Sun, HP e Dell nella fascia di mercato dei server Unix sopra i 10.000 dollari.

La nuova famiglia di eServer è composta da quattro modelli: il p5-520 , a doppio processore; il p5-550 , da due a quattro vie; il p570 , con supporto fino a 16 CPU; e il p5-570 Express, più economico del precedente e capace di supportare fino ad un massimo di 8 processori.

I server p5-520 e p5-550 sono disponibili, oltre che in formato tower (deskside), anche in configurazioni rack-mount 4U (17,8 cm) e, a partire da settembre, 1U (4,4 cm) e 2U (8,9 cm). Più avanti IBM conta di introdurre anche un modello di server in grado di supportare configurazioni a 64 processori.

Il modello p5-520, proposto nelle configurazioni deskside o per montaggio su rack, si presenta come un server entry level a 2 vie che utilizza un microprocessore Power5 a 1,65 GHz con un massimo di 32 GB di memoria e OS AIX 5L o Linux. Il modello deskside o rack-mount p5-550, scalabile fino alla configurazione a 4 vie, è equipaggiabile con microprocessori Power5 a 1,65 GHz, un massimo di 64 GB di memoria e OS AIX5L o Linux. Il sistema mid-range p5-570, scalabile fino a 16 processori Power5 a 1,9 GHz, supporta gli OS AIX5L, Linux o i5/OS, il sistema operativo OS/400 di nuova generazione. Il modello p5-570 Express sarà disponibile con processori a 1,5 GHz e un massimo di 256 GB di memoria.

I prezzi di questi sistemi variano dai circa 12.900 dollari del p5-520 ai circa 25.900 dollari del 570.

I nuovi eServer p5 condividono lo stesso hardware di base dei sistemi iSeries lanciati a giugno, e si mantengono completamente compatibili con l’attuale generazione di eServer pSeries. IBM sostiene che i nuovi p5 sono i primi server Unix ad offrire alle aziende la possibilità di supportare per ogni processore più server virtuali, denominati “partizioni logiche dinamiche”, e di riconfigurare automaticamente tali partizioni (“in meno di un secondo”, a detta di Big Blue) per rispondere all’evoluzione delle esigenze. I p5 offrono anche la possibilità di utilizzare più sistemi operativi, tra cui AIX5L 5.2, AIX5L 5.3, Linux (Red Hat e Novell SuSE) e il nuovo IBM i5/05, in maniera simultanea: questo è reso possibile dalla nuova tecnologia Virtualization Engine, capace di supportare fino a 10 sistemi operativi per singola CPU.

“Traendo pieno vantaggio dalle caratteristiche dell’OS di nuova generazione IBM AIX5L, i clienti avranno l’opportunità di sfruttare le capacità di virtualizzazione dei server IBM eServer p5 come il micro-partizionamento, i pool di processori condivisi, l’input/output virtuale e le LAN virtuali”, ha spiegato IBM in un comunicato.

La più grande novità tecnologia alla base dei nuovi server è data, come premesso, dai processori Power5. Questi chip, contenenti 276 milioni di transistor e costruiti con una tecnologia al rame SOI da 0,13 micron, supportano il multi-threading simultaneo: similmente all’Hyper-Threading di Intel, questa tecnologia permette di trasformare un unico processore fisico in due processori logici visti come tali da applicazioni e sistemi operativi, permettendo l’esecuzione contemporanea di due thread applicativi in modo da ridurre i tempi di completamento dei vari task. Il multi-threading simultaneo assicura, secondo IBM, aumenti fino al 40% delle prestazioni con le applicazioni server.

I Power5 integrano poi una nuova tecnologia per le gestione dinamica dell’alimentazione che permette di “staccare la corrente” alle porzioni di core, cache o switch non utilizzate, consentendo al processore di consumare un quantitativo di elettricità allineato al suo effettivo carico di lavoro.

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

  • Akiro scrive:
    Re: mi fa un po' tenerezza

    (troll)(troll)(troll)(troll)(troll)se lo dici tu...
  • Anonimo scrive:
    Re: No, non ho capito bene...
    ma che dici?non parlare di cose che non conosci, la gestione della idt è una cosa puramente dell'os, ad esempio su win9x/me esiste un trick (usato per la prima volta dal CIH), che permette di sovrascrivere la idt senza problemi, questo perché la memoria della idt non è protetta su win9x/me, infatti basta usare l'istruzione sidt e hai l'indirizzo della idt, poi ci scrivi quello che vuoisui sistemi nt invece la idt è protetta, e l'unico modo ad oggi conosciuto per scriverci sopra (oltre ad usare un driver a ring 0), consiste nell'utilizzare il device DevicePhysicalMemory che permette di mappare qualsiasi indirizzo fisico nell'address space del processo chiamante, ti prendi l'indirizzo della idt, lo converti in un indirizzo fisico, e lo mappi, da li usando un po' di trucchetti più o meno noti (cambiare gli acl e cacchi vari), riesci sia a leggere che a scrivere la idt (ma anche la gdt)prendilo come un consiglio, non sparare tutti i termini tecnici che conosci a casaccio (cpl, dpl, ecc...), ma il manuale dell'intel leggilo bene, dall'inizio alla fine, non a pezzi
  • Anonimo scrive:
    Re: No, non ho capito bene...
    tralasciando le altre risposte fatte da gente che al massimo può zappare la terra e raccogliere le patate (e pelarle poi), i trick anti-debug sono molti, prima di tutto c'è l'api IsDebuggerPresent che controlla se il processo in esecuzione sta venendo debuggato oppure se c'è un debugger di sistema attivo, poi ad esempio per alcuni debugger più o meno noti (tipo SoftICE) è possibile vedere se il suo driverè caricato tramite CreateFile, ancora su sistemi win9x/me SoftICE ha una command iterface accessibile tramite l'int 3, per mandargli comandi in remoto, se risponde significa che c'è SoftICE, poi puoi rendere quasi impossibile il tracing, mettendo un SEH (structured exception handling, ovvero gestione strutturata delle eccezioni, una feature nativa di win, per la quale è possibile installare all'inizio di una funzione, un gestore delle eccezioni che viene chiamato dal sistema al verificarsi di un eccezione, il gestore poi può sapere cos'è successo, se continuare o no e altra roba) sull'int 1, usando la tecnica del trap flag (o altre tecniche), in questo modo se il codice viene tracciato step-by-step (cosa che comunemente fa chi debugga), vieni portato a codice "diverso" da quello vero che viene eseguito se non stai tracciando il programma (praticamente se non tracci, viene eseguito il codice della SEH, se tracci, il debugger ovviamente gestisce l'int 1, quindi il codice vero (quello della seh) non viene eseguito, quindi ti ritrovi in codice fittizio che non serve a niente)poi ancora su win9x/me puoi rimappare gli int 1 e 3, così se uno prova ad usarli magari crasha il sistema, puoi farlo pure su nt ma con tecniche più complicate (e comunqe sia può farlo solo un eseguibile che gira con privilegi di amministratore e per farlo è necessario cambiare alcuni attributi di un device, insomma niente di semplice)insomma i modi sono infiniti, alcuni più o meno famosi altri meno noti, non c'è niente di rivoluzionario o chissà cosa, tra l'altro i virus dei tempi del dos facevano questo e altro, anche perché col dos avevi più libertà sul controllo della macchina (beh stando in real mode è normale daltronde)
  • Anonimo scrive:
    Re: No, non ho capito bene...
    - Scritto da: Anonimo


    anche torturarlo :D

    ... gli invertivi i tutti jump che vedevi ?
    :D:D:DSi, e poi alteravo bytes a casaccio nel codice ancora da eseguire... :D(per chi legge: sto scherzando... non avrebbe molto senso)
  • Anonimo scrive:
    Re: No, non ho capito bene...
    - Scritto da: Anonimo
    il mio era solo un esempio semplice (il piu'
    semplice) di come puo' essere fatto un
    programma antidebbugger che potrebbe fermare
    un lamer, ma poi come è fatto questo
    worm: quale delle tante e avanzate tecniche
    che usa per il suo lavoro di mascheramento
    contro debugger ecc.. non lo so'.......Ah, si... capisco. Il fatto e` che io consideravo quelle tecniche di criptaggio come modi di nascondere il codice, mentre questo uhm... "anti-debugging" come me lo aveva presentato l'articolo mi sembrava qualcosa di completamente nuovo e non riuscivo a capire in cosa consisteva e come funzionava.
  • Anonimo scrive:
    Re: No, non ho capito bene...

    anche torturarlo :D... gli invertivi i tutti jump che vedevi ? :D:D:D
  • Anonimo scrive:
    Re: No, non ho capito bene...
    - Scritto da: Alex¸tg
    - Scritto da: Anonimo

    non possono essere saltate....se il
    valore

    di ritorno della funzione che "vede" il

    debugger è per esempio 0x78 (=non

    c'è il debugger) allora è

    okay, in ogni altro caso no. Con questo

    valore il programma fa un XOR con tutti
    i

    byte in un vettore...questi byte con XOR

    0x78 diventano opcode che scritto in
    memoria

    viene eseguito.... se la funzione viene

    saltata o il numero in uscita è
    un

    numero casuale diverso da 0x78 allora il

    programma non funzionerà mai

    perchè il vettore decriptato

    conterrà solo numeri casuali e
    non

    funzionanti per l'assembly...!
    così

    il codice è nascosto (tipo un
    RET il

    cui opcode è C3 con XOR 78

    sarà 0xBB) e se il numero per
    l'XOR

    è diverso da 0x78 non

    diventerà un RET ma un altro

    numero...

    ...poi per scrivere tutti i nuovi byte
    in

    memoria si richiamerà la api

    writeprocessmemory....



    ...poi esistono altre cose ma sono
    troppo

    complicate (sopratutto lunghe...) da

    spiegare... -__-

    Ah, grazie per la spiegazione.
    Capisco: i soliti trucchetti, insomma. Mah,
    resta il fatto che se le cose stanno cosi`,
    non e` niente di sensazionale. Il
    mascheramento del codice con XOR e shiftings
    e` roba molto vecchia. Diciamo che la o
    notizia e`... un po' gonfiata, o il debugger
    (come persona) non sapeva quanto vecchi
    fossero questi trucchi... oppure il trucco
    non e` niente del genere...il mio era solo un esempio semplice (il piu' semplice) di come puo' essere fatto un programma antidebbugger che potrebbe fermare un lamer, ma poi come è fatto questo worm: quale delle tante e avanzate tecniche che usa per il suo lavoro di mascheramento contro debugger ecc.. non lo so'.......
  • Anonimo scrive:
    Re: mi fa un po' tenerezza
    - Scritto da: Akiro
    8 )

    (linux)(troll)(troll)(troll)(troll)(troll)
  • Anonimo scrive:
    Re: No, non ho capito bene...
    - Scritto da: Anonimo
    non possono essere saltate....se il valore
    di ritorno della funzione che "vede" il
    debugger è per esempio 0x78 (=non
    c'è il debugger) allora è
    okay, in ogni altro caso no. Con questo
    valore il programma fa un XOR con tutti i
    byte in un vettore...questi byte con XOR
    0x78 diventano opcode che scritto in memoria
    viene eseguito.... se la funzione viene
    saltata o il numero in uscita è un
    numero casuale diverso da 0x78 allora il
    programma non funzionerà mai
    perchè il vettore decriptato
    conterrà solo numeri casuali e non
    funzionanti per l'assembly...! così
    il codice è nascosto (tipo un RET il
    cui opcode è C3 con XOR 78
    sarà 0xBB) e se il numero per l'XOR
    è diverso da 0x78 non
    diventerà un RET ma un altro
    numero...
    ...poi per scrivere tutti i nuovi byte in
    memoria si richiamerà la api
    writeprocessmemory....

    ...poi esistono altre cose ma sono troppo
    complicate (sopratutto lunghe...) da
    spiegare... -__-Ah, grazie per la spiegazione.Capisco: i soliti trucchetti, insomma. Mah, resta il fatto che se le cose stanno cosi`, non e` niente di sensazionale. Il mascheramento del codice con XOR e shiftings e` roba molto vecchia. Diciamo che la o notizia e`... un po' gonfiata, o il debugger (come persona) non sapeva quanto vecchi fossero questi trucchi... oppure il trucco non e` niente del genere...
  • Akiro scrive:
    mi fa un po' tenerezza
    8 )(linux)
  • Anonimo scrive:
    Re: No, non ho capito bene...
    - Scritto da: MemoRemigi

    - Scritto da: dilbert68


    Un modo che ha un software per capire se

    è eseguito tramite debugger,
    è

    di fare timestamping tra una sua
    istruzione

    e una successiva, e verificare che il
    tempo

    passato non sia "enorme":

    cosa che avviene infatti quando viene

    eseguito tramite debugger, è

    l'analizzatore che preme il tasto "next

    step" e normalmente lo fa ad intervalli

    dell'ordine del secondo, che sono

    un'enormita ovviamente per la scala
    interna

    dei tempi di esecuzione, in assenza di

    debugger.

    Ok mi sembra giusto, però ho un
    dubbio, come fa il codice a fare
    timestamping delle istruzioni ?
    Non sono esperto di ASM ma credo che per are
    ciò debba usare altre istruzioni...
    che con un debugger possono essere
    semplicemente saltate... o no ? :onon possono essere saltate....se il valore di ritorno della funzione che "vede" il debugger è per esempio 0x78 (=non c'è il debugger) allora è okay, in ogni altro caso no. Con questo valore il programma fa un XOR con tutti i byte in un vettore...questi byte con XOR 0x78 diventano opcode che scritto in memoria viene eseguito.... se la funzione viene saltata o il numero in uscita è un numero casuale diverso da 0x78 allora il programma non funzionerà mai perchè il vettore decriptato conterrà solo numeri casuali e non funzionanti per l'assembly...! così il codice è nascosto (tipo un RET il cui opcode è C3 con XOR 78 sarà 0xBB) e se il numero per l'XOR è diverso da 0x78 non diventerà un RET ma un altro numero... ...poi per scrivere tutti i nuovi byte in memoria si richiamerà la api writeprocessmemory.......poi esistono altre cose ma sono troppo complicate (sopratutto lunghe...) da spiegare... -__-
  • Anonimo scrive:
    Re: questo worm è geniale.

    Geniale è chi costruisce, non chi
    crea scompiglio e caos fini a sè
    stessi. In quest'ultimo caso si può
    parlare di idioti sapienti, ma non certo di
    geni.Allora chi ha costruito l'atomica é un idiota sapiente :D
  • Anonimo scrive:
    Re: No, non ho capito bene...

    Perché non posti qualche link, visto
    che li hai trovati?Perchè è meglio se i bambini imparano a camminare da soli!E poi giocare con le pistole non è un passatempo per i bravi bambini :D
  • Anonimo scrive:
    Re: No, non ho capito bene...
    Perché non posti qualche link, visto che li hai trovati?
  • cico scrive:
    Re: panda antivirus

    è bene ricordare che è o era
    legato a scientologySei sicuro? Hai qualche link?Sono assolutamente contro, disdico immediatamente la licenza e mi compero Avast.
  • theDRaKKaR scrive:
    Re: No, non ho capito bene...
    proprio così
  • MemoRemigi scrive:
    Re: No, non ho capito bene...
    - Scritto da: dilbert68
    beh in linea di principio sì, possono
    essere saltate;
    più che altro sarebbe necessario[etc]Grazie per la spiegazione !
  • Anonimo scrive:
    Qualcuno chiedeva info su anti-debugging
    Anti-debugging in Win32 - Lord Julus -1999http://vx.netlux.org/lib/vlj05.htmlWin32 Anti-Debugging tricks - Billy Belcebuhttp://library.succurit.com/virus/ANTIDEBG.TXTLinux anti-debugging techniques (fooling the debugger) - Silvio Cesare - January 1999http://vx.netlux.org/lib/vsc04.htmlun sito interessante per i programmatori in "erba" :D (e non solo)http://www.secureprogramming.com
  • dilbert68 scrive:
    Re: No, non ho capito bene...

    Ok mi sembra giusto, però ho un
    dubbio, come fa il codice a fare
    timestamping delle istruzioni ?
    Non sono esperto di ASM ma credo che per are
    ciò debba usare altre istruzioni...
    che con un debugger possono essere
    semplicemente saltate... o no ? :obeh in linea di principio sì, possono essere saltate; più che altro sarebbe necessario saltare le istruzioni che fanno il test sulla differenza dei timestamp, saltando direttamente alla label del caso in cui il test è verificato. Niente è impossibile qui, semplicemente ci vuole più impegno da parte di chi usa il debugger: non può più assumere che il flusso di controllo del virus sia indipendente dal timing dell' esecuzione delle istruzioni, e deve capire quali sono i tests che controllano questo timing per bypassarli manualmente. Se poi il codice del virus è in grado di modificare se stesso, nella fattispecie spostando la posizione di questi tests, ancora più difficle perchè salta l'assunzione che questi tests si trovino in determinati punti fissi del codice.
  • Anonimo scrive:
    Re: No, non ho capito bene...

    1) il debugger usa una chiamata ad un
    interrupt (il 3 credo, sono anni che non lo
    uso).. il software basta che lo reindirizzi
    e il debugger va' a farsi friggere.. in
    pratica il software si accorge che lo stai
    eseguendo tramite un debugger perche' il
    debugger si antepone alla cpu
    nell'esecuzione dell'istruzione assembler..
    e per anteporsi deve usare un interrupt.Il debugger dovrebbe funzionare così:viene attivato impostando un flag (TRACE ad esempio) la cpu così dopo ogni istruzione genera un interrupt specifico. L'interrupt esegue il suo handler il cui indirizzo è in una tabella.Ma come fa il virus a modificare l'indirizzo dell'handler dell'interrupt?Queste sono operazioni che di solito fanno fatte in modalità supervisore della CPU. Solo l'OS dovrebbe essere in grado di farle.Se qualcuno ha le idee più chiare si faccia avanti:|
    • Anonimo scrive:
      Re: No, non ho capito bene...

      Ma come fa il virus a modificare l'indirizzo
      dell'handler dell'interrupt?
      Queste sono operazioni che di solito fanno
      fatte in modalità supervisore della
      CPU. Solo l'OS dovrebbe essere in grado di
      farle.

      Se qualcuno ha le idee più chiare si
      faccia avanti
      :|GOOGLE le ha chiarissime :)
    • Anonimo scrive:
      Re: No, non ho capito bene...
      - Scritto da: Anonimo

      1) il debugger usa una chiamata ad un

      interrupt (il 3 credo, sono anni che
      non lo

      uso).. il software basta che lo
      reindirizzi

      e il debugger va' a farsi friggere.. in

      pratica il software si accorge che lo
      stai

      eseguendo tramite un debugger perche' il

      debugger si antepone alla cpu

      nell'esecuzione dell'istruzione
      assembler..

      e per anteporsi deve usare un interrupt.

      Il debugger dovrebbe funzionare così:
      viene attivato impostando un flag (TRACE ad
      esempio) la cpu così dopo ogni
      istruzione genera un interrupt specifico.
      L'interrupt esegue il suo handler il cui
      indirizzo è in una tabella.Si, questo e` l'altro modo (a parte l'infilare un breakpoint, una chiamata all'interrupt 3) di farlo funzionare. Sfrutta la circuiteria specificamente aggiunta dall'architettura i386 in poi.
      Ma come fa il virus a modificare l'indirizzo
      dell'handler dell'interrupt?
      Queste sono operazioni che di solito fanno
      fatte in modalità supervisore della
      CPU. Solo l'OS dovrebbe essere in grado di
      farle.Gia`, in entrambi i casi non e` possibile raggiungere la IDT.La IDT e` la tabella dei descrittori degli interrupt, ovvero la tabella che contiene indirizzi e diritti di accesso al codice che reagisce a ogni vettore di interrupt. Pero` la IDT si trova in una delle parti della memoria che il sistema protegge. Per arrivarci si dovrebbe ottenere un CPL (Curret Privilege Level) pari a zero, mentre le applicazioni e i worm girano a CPL=3. E naturalmente non e` possibile: ecco, la vera innovazione per un virus sarebbe riuscire a fare questo, ma non ho idea di come potrebbe riuscisci. Oddio, poi, sfruttando le falle dei buffer overrun ci sono riusciti in molti, ma non certo ALL'INIZIO del proprio codice, ergo ci sarebbe tutto il tempo che vuoi per arginare la chiamata che sappiamo andare a bersagliare un'area vulnerabile del sistema operativo in cui si verifichera` un buffer overrun.
      Se qualcuno ha le idee più chiare si
      faccia avanti
      :|Credo di aver capito che a ogni modo si parli di espedienti noti per aggirare il debugging quando il tecnico che fa il debugging non e` abbastanza esperto, ovvero di vecchi trucchi. Io invece avevo sospettato che il virus avesse trovato un modo certo per evitare di venire studiato... devo aver frainteso, insomma.
  • Anonimo scrive:
    Re: panda antivirus

    è bene ricordare che è o era
    legato a scientology
    oltre al fatto che alcune versioni
    impestavano di spyware
    e che altre ne rendevano oltremodo difficile
    la disinstallazione e andavano in conflitto
    con molti altri software
    spero che le difficoltà di analisi
    siano dovute alla concezione del virus e non
    al talento degli analistiForse ti confondi con il norton :D
  • Anonimo scrive:
    No, e' correto cosi'
  • MemoRemigi scrive:
    Re: panda antivirus
    - Scritto da: Anonimo
    è bene ricordare che è o era
    legato a scientologyNAAAAAAAAAAAAAAAA!!!!Questa proprio non la sapevo !!!
  • MemoRemigi scrive:
    Re: No, non ho capito bene...
    - Scritto da: dilbert68
    Un modo che ha un software per capire se
    è eseguito tramite debugger, è
    di fare timestamping tra una sua istruzione
    e una successiva, e verificare che il tempo
    passato non sia "enorme":
    cosa che avviene infatti quando viene
    eseguito tramite debugger, è
    l'analizzatore che preme il tasto "next
    step" e normalmente lo fa ad intervalli
    dell'ordine del secondo, che sono
    un'enormita ovviamente per la scala interna
    dei tempi di esecuzione, in assenza di
    debugger.Ok mi sembra giusto, però ho un dubbio, come fa il codice a fare timestamping delle istruzioni ?Non sono esperto di ASM ma credo che per are ciò debba usare altre istruzioni... che con un debugger possono essere semplicemente saltate... o no ? :O
  • Anonimo scrive:
    panda antivirus
    è bene ricordare che è o era legato a scientologyoltre al fatto che alcune versioni impestavano di spywaree che altre ne rendevano oltremodo difficile la disinstallazione e andavano in conflitto con molti altri softwarespero che le difficoltà di analisi siano dovute alla concezione del virus e non al talento degli analisti
  • blackneo scrive:
    non è il solo
    sembra che vi stupite...... anche un pò di anni fa i love you ha fatto strage..... e negli ultimi anni virus del tipo netsky continuano a girare anche dopo mesi che sono stati scoperti ( io ne ricevo 30 al giorno di spam contenente netsky) è normale che i virus diventino sempre più raffinati,è l'evoluzione.
  • Anonimo scrive:
    Re: No, non ho capito bene...

    in
    pratica il software si accorge che lo stai
    eseguendo tramite un debugger perche' il
    debugger si antepone alla cpu
    nell'esecuzione dell'istruzione assembler..
    e per anteporsi deve usare un interrupt.eeeeh???
  • Anonimo scrive:
    Re: Il vecchio disassembler...

    ... era divertente rimappare le chiamate
    all'int 21 sull'NMI....
    e i salti intra-istruzione? bisognava usare
    il cervello per mascherare le routine di
    crittazione...
    Il massimo era buttare del codice nella
    tabella con la mappatura degli interrupt,
    era pauroso debuggare una cosa del genere...Toh! Uno che sa :)
    purtroppo ora queste finezze non le usano
    più :(Adesso ne usano altre, si chiama progresso :)
  • Anonimo scrive:
    Re: Il vecchio disassembler...
    ... era divertente rimappare le chiamate all'int 21 sull'NMI....e i salti intra-istruzione? bisognava usare il cervello per mascherare le routine di crittazione...Il massimo era buttare del codice nella tabella con la mappatura degli interrupt, era pauroso debuggare una cosa del genere...purtroppo ora queste finezze non le usano più :(
  • la redazione scrive:
    Re: Per la redazione
    Un po' di "slang" informatico ogni tanto non fa male, su ;-) Altrimenti rischiamo di trasformarci in fricchettoni imbalsamati :-DCiao!- Scritto da: Anonimo
    Credo che sia più corretto
    "decompresso" o "non compresso" piuttosto
    che il brutto "scompresso". No?
  • Anonimo scrive:
    Re: No, non ho capito bene...
    - Scritto da: Alex¸tg
    ...come farebbe a opporsi a un debugger?ti parlo in merito al buon vecchio assembler x86 puro (niente a che vedere con api windows et similia):1) il debugger usa una chiamata ad un interrupt (il 3 credo, sono anni che non lo uso).. il software basta che lo reindirizzi e il debugger va' a farsi friggere.. in pratica il software si accorge che lo stai eseguendo tramite un debugger perche' il debugger si antepone alla cpu nell'esecuzione dell'istruzione assembler.. e per anteporsi deve usare un interrupt.2) il disassembler (programma che dal compilato riporta il sorgente assembler) e' sempre stato un fallimento per quanto riguarda l'analisi di virus polimorfici, soprattutto se criptati.. chi conosce l'assembler sa cosa significhi una modifica nello stack del codice da eseguire..
  • Anonimo scrive:
    Re: Non ho capito bene...[redazione!]

    Non ne sono sicuro, ma provo a risponderti:
    Essendo compresso, prima va decompresso, e
    questo implica che deve essere eseguito.... fermati qui e lascia perdere. Se le cose non le sai forse faresti meglio a tacere
    Inltre (ma è una mia ipotesi) se
    utilizza sw auto modificante (cioè
    modifica il codice stesso intanto che si
    esegue) proprio il disassembler non funziona
    più (o meglio: una gran confusione e
    non capisci più nulla!).azzo una NUOVA tecnica!La prima volta che l'ho vista girava su un apple II
  • Parliamone scrive:
    Re: Il vecchio disassembler...
    - Scritto da: HotEngine
    Alla McAfee non lo conoscono? Hanno bisogno
    del debug a tutti i costi ? Rotfl... ;)E dove leggi che hanno bisogno del debugger a tutti i costi?"Oltre ad adottare un efficace meccanismo di cifratura, il vermicello è infatti in grado di accorgersi se qualcuno, come un laboratorio antivirus, tenta di analizzare il suo codice attraverso strumenti come i debugger"Mi sembra ovvio che prima si tenti la strada facile (ovvero il debugger), e solo in seguito, se serve, si mette mano al disassembler: se il debugger è sufficiente, tanto di guadagnato. Non mi pare che nessuno abbia dichiarato "Non siamo riusciti a usare il debugger e quindi abbiamo lasciato perdere l'analisi".
  • The Raptus scrive:
    Re: Non ho capito bene...[redazione!]
    Non ne sono sicuro, ma provo a risponderti:Essendo compresso, prima va decompresso, e questo implica che deve essere eseguito. L'algoritmo di decvompressione (e soprattutto il codice che lo esegue) non è certo winzip, ma qlc di modificato all'uopo. Ecco perchè se si incomincia a fare debugging non si può proprio disassemblare!Inltre (ma è una mia ipotesi) se utilizza sw auto modificante (cioè modifica il codice stesso intanto che si esegue) proprio il disassembler non funziona più (o meglio: una gran confusione e non capisci più nulla!).Tieni conto che i micro hanno anche delle istruzioni "in più" che possono essere eseguite solo in modalità SV (superVisor). Niente di più facile che il codicillo usi qualche trucco in questo senso.Per qusto chiederei alla redazione se è possibile trovare qualche link a questa notizia! Grazie.
  • Anonimo scrive:
    Re: Il vecchio disassembler...
    - Scritto da: Anonimo
    se e' compresso/criptato con il disassmbler
    non ci fai nulla...Non ci farai nulla tu. :-DIl codice non è compresso/criptato al 100%, perché la routine di decompressione/decriptazione è comunque in chiaro.Quindi col disassembler puoi benissimo individuare la routine di decompressione/decriptazione, decomprimere e decriptare il resto dei dati ottenendo il codice per la CPU e da quel momento in poi continui con il disassembler lavorando sul codice in chiaro.Una volta 'sta roba era banale routine. Oggi se beccano un worm che chiude il debugger rimangono stupiti! :-D
  • Anonimo scrive:
    No, non ho capito bene...
    ...come farebbe a opporsi a un debugger?Cioe`, a casa mia un debugger funziona eseguendo normalmente in "trace", ovver eseguendo un istruzione per volta del programma da spulciare. Ma il programma oggetto dell'indagine non viene eseguito affatto previo consenso di chi sta controllandolo, centellinando le istruzioni, tramite il debugger, e quindi? Boh? Come funzionerebbe, sarei curioso di sapere... da un post di sotto leggo un riferimento a un API "IsDebuggerPresent", ma... una chiamata ad una API e` un'istruzione, possibile che chi debugga non si accorga di quel che il worm tentera` di fare con tale chiamata PRIMA che la faccia, e quindi chi debugga semplicemente non possa saltare quell'istruzione? Nei debugger si puo` fare di tutto, a meno che non mi sia perso qualcosa di recente e/o che la stupidaggine dei sistemi di sviluppo di oggi sia peggiorata piu` di quanto pensassi.
    • dilbert68 scrive:
      Re: No, non ho capito bene...
      dall'articolo:"Nel caso in cui ritiene di essere "spiato", il worm smette di funzionare e chiude automaticamente il suo processo"Un modo che ha un software per capire se è eseguito tramite debugger, è di fare timestamping tra una sua istruzione e una successiva, e verificare che il tempo passato non sia "enorme": cosa che avviene infatti quando viene eseguito tramite debugger, è l'analizzatore che preme il tasto "next step" e normalmente lo fa ad intervalli dell'ordine del secondo, che sono un'enormita ovviamente per la scala interna dei tempi di esecuzione, in assenza di debugger.
  • Anonimo scrive:
    Re: questo worm è geniale.
    Cambiano i tempi. Ai miei tempi l'undelete di Norton era considerato geniale... la differenza è sostanziale. Geniale è chi costruisce, non chi crea scompiglio e caos fini a sè stessi. In quest'ultimo caso si può parlare di idioti sapienti, ma non certo di geni.
  • Anonimo scrive:
    questo worm è geniale.
    sic
  • Anonimo scrive:
    Re: Il vecchio disassembler...
    certo che è roba tosta,, fare virus,,,
  • Anonimo scrive:
    Re: Per la redazione
    Volevate forse volevano dire scompattato ?Osso di Seppia
  • Anonimo scrive:
    Per la redazione
    Credo che sia più corretto "decompresso" o "non compresso" piuttosto che il brutto "scompresso". No?
  • Anonimo scrive:
    Re: Il vecchio disassembler...
    se e' compresso/criptato con il disassmbler non ci fai nulla...va prima decriptato/dumpato poi vedere se usa l'api isDebuggerPresent o altri trucchi contro il debugging e poi ci possono lavorare :P
  • HotEngine scrive:
    Il vecchio disassembler...
    Alla McAfee non lo conoscono? Hanno bisogno del debug a tutti i costi ? Rotfl... ;)
Chiudi i commenti