OllyDbg un ottimo debugger, operante in ambiente Windows a 32bit, possiamo descriverlo con tre aggettivi: rapido, efficace e semplice da usare. Sostituisce l'ormai vecchio Softice e non teme confronti con nessun'altro debugger Windows. Ottimo anche per chi è poco esperto, grazie alla sua intuitiva interfaccia grafica.
OllyDbg è un debugger Windows, ossia un programma nato per analizzare il codice sorgente di un software e scoprirne eventuali bug oppure utilizzarlo per fare del reversing. Il codice sorgente viene mostrato in assembly, esso non è altro che un linguaggio di programmazione che si avvicina al linguaggio macchina dei computer.
Se non lo avete presente, un esempio di linguaggio assembly può essere il seguente:
MOV BYTE PTR DS:[42F4D5],AL
LEA EAX,DWORD PTR SS:[EBP-14]
PUSH EAX
Con un debugger, come detto prima possiamo analizzare un codice di un programma, ad esempio possiamo impostare dei breakpoint, ossia delle interruzioni che fanno fermare l’esecuzione del programma, e ci consentono di analizzare piccole porzioni di codice del programma che stiamo analizzando.
Come debugger è molto apprezzato nella comunità informatica perché è open source, funziona unicamente a 32 bit su sistemi Windows, si possono installare svariati plug-in e soprattutto ha un’interfaccia grafica che lo rende molto facile ed intuitivo rispetto agli altri debugger esistenti, l’unico punto debole che ha è che funziona a livello ring3, ossia usermode rispetto al famoso debugger SoftICE della NuMega che lavora a ring0.
Per chi non sapesse cosa si intende per lavorare a ring0 o a ring3 ecco la spiegazione:
I ring sono dei livelli di privilegio e/o di sicurezza che un processore fornisce, ad esempio parlando di processori x86 i ring vanno da 0 a 3. Per semplificare il concetto immaginiamo il computer come la terra, dove la superficie è il ring3(Applicativi software), il secondo strato è il ring2 e così via, arriviamo al centro della terra e troviamo il ring0(Kernel)
Ritornando ad OllyDbg, anche se funziona a ring3, và benissimo per analizzare le applicazioni di tutti i giorni.
Diamo uno sguardo prima ai requisiti per farlo funzionare correttamente:
Processore: x86
Sistema operativo: Microsoft Windows 95, Windows 98, Windows NT 4, Windows 2000,
Windows Xp, Windows Vista e Windows 7
Ram: 64 MB (128 MB consigliata)
Hard disk: 2 MB liberi
Questa è l’interfaccia grafica di Ollydbg:
Da questa interfaccia si può vedere il codice macchina di un programma, cosa contiene ogni indirizzo di memoria del processore e come vengono passate le informazioni tra un registro e l’altro, si può dire che questa finestra chiamata CPU è il cuore di tutto il nostro programma.
Esistono diverse finestre che possiamo aprire tra le quali:
Log: Mostra i plug-in e i moduli caricati in memoria
Memory: Mostra come il computer assegna la memoria per un determinato programma che
vogliamo debuggare.
Excutable Modules: Mostra tutti i moduli caricati dal programma, per modulo si intende ad
esempio le DLL che il programma richiama durante tutta la sua
esecuzione.
Esistono tante altre interfacce disponibili, basta richiamarle dal menu View per vedere cosa contengono.
Con questa immagine faccio vedere solo alcune delle principali finestre che possiamo aprire:
Cosa molto importante, come detto prima, è la possibilità di gestire i breakpoint in modo molto semplice, si possono impostare ad esempio alla voce nel menu Plug in e poi Command line. Avendo impostato ad esempio un determinato breakpoint il programma alla sua prima esecuzione si fermerà proprio nel punto desiderato e dà lì potremo leggere e/o modificare i registri, modificare il nostro codice sorgente e commentare il codice a nostro piacimento.
Altra cosa molto importante è la funzione Step, ossia la possibilità di far avanzare il codice sorgente manualmente istruzione dopo istruzione, esistono diversi tipi di step, i principali sono:
Step into: ossia se nell’esecuzione del programma incontriamo una call, ossia una
chiamata ad un funzione,OllyDbg salta all’interno facendoci vedere che codice
viene eseguito in quella determinata funzione.
Step over: esegue un operazione un po’ diversa da Step into, ossia passa sopra quella
funzione andando all’istruzione dopo di essa, questo step non entrando
all’interno di una funzione non mostra cosa è contenuto al suo interno, ma si
limita unicamente ad eseguirla senza farla vedere.
Come detto prima OllyDbg consente di installare dei plug-in aggiuntivi, sono molto utili ad esempio se il programma che vogliamo andare a debuggare incorpora dei meccanismi di protezione in esso che non consentono il debug, attivando questi plug-in possiamo tranquillamente vedere la corretta esecuzione del programma.
Per ulteriori informazioni e dettagli sul programma consiglio di andare a leggere tutta la documentazione in inglese sul sito ufficiale, inoltre per chi volesse scaricare il programma consiglio la versione 1.10 che si può scaricare liberamente dal sito: http://www.ollydbg.de/
Non ho avuto mai l’occasione di usare questi strumenti di debug così approfonditi ma credo che siano tanto utili quanto affascinanti, infatti credo che, soprattutto per chi sviluppa software di basso livello, vedere in che modo lavorano i processori come quelli che i moderni PC hanno a bordo, è sempre qualcosa di molto interessante.
Certamente leggere il codice assembler non è agevole quanto leggere un listato scritto con un linguaggio ad oggetti (soprattutto se il codice assembler è stato creato dal compilatore avremo che i nomi delle variabili si assomigliano tra loro, cosa che rende ancora più difficile la lettura del codice) ma sicuramente ha la sua utilità oltre che a suscitare curiosità.
Utile la funzione di mostrare in che modo il PC sta allocando la memoria al programma in esame, come altrettanto utile è la funzione di poter inserire i breakpoint e quindi quella di poter eseguire step-by-step il programma. Insomma un debug di basso livello veramente completo…il massimo sarebbe avere un plug-in o una funzione che identifica e ricostruisce le classiche strutture della programmazione come i cicli, gli “if”, i “case” e così via (magari con un’opportuna interfaccia grafica), renderebbe la lettura del codice assembler ancora più agevole.
La possibilità di vedere i moduli dal programma potrebbe essere utile per vedere le dipendenze che il software in esame ha con il resto delle librerie di windows…riesce anche ad analizzare il codice di suddetti moduli? farebbe guadagnare ancora punti in più a questo software.
Altro aspetto positivo sono le ridotte dimensioni e che riesce a funzionare su sistemi operativi oramai datati; aspetti negativi secondo me, oltre al non poter scendere fino al livello ring0, è di non funzionare con sistemi operativi come linux o mac e di non riuscire a lavorare con sistemi a 64 bit: oramai i PC a 64 iniziano a diffondersi e piano piano sostituiranno quasi completamente i 32 bit.
Utile si per fare il debug e il reverse ma soprattutto direi che è utile per chi vuole fare hacker 🙂
Ciao..interessante articolo..
Sinceramente non avevo mai visto un debugger sotto Windows..ma ho utilizzato soltanto GDB su linux…quindi grazie per aver dato tutte le spiegazioni in maniera chiara direi ;)..
A quanto pare le funzionalità che hai descritto sono quelle standard di ogni debugger di rispetto, per questo volevo farti alcune domande…
E’ possibile debuggare un programma guardando soltanto il codice assembler di alcune funzioni..e non l’intero codice..ad esempio se ho una funzione nel mio main..e voglio guaradre solo quella e non tt il main..si potrebbe fare no?
Se invece volessi debugger col mio pC(host) un altro pc(target) come si potrebbe fare..solo via seriale o anche via ethernet?
(..Ad esempio se volessi debugger un cell con windows phone sopra.. :)..)
Quando hai citato dei programmi di protezione..a cosa ti riferisci? Hai un esempio in particolare..?Magari qualche hack 😉 sarebbe interessante da vedere questo debugger anche n funzione…appena ho tempo cerco anch’io qualcosa..ma se hai già qualke link ben vengano 😉
Grazie, ciao
Ciao a tutti,
Per lucagiuliodori:
la risposta alla tua domanda in merito alla possibilità di vedere i moduli dal programma è si, puoi vedere qualunque modulo che il programma target richiama e necessita per la sua corretta esecuzione, compreso la struttura completa del singolo modulo, basta andarla a richiamare. Poi comunque già solo quando debuggi un programma OllyDbg passa da un modulo all’altro mostrando il disassemblato del modulo in cui sei. Purtroppo non esiste per i PC a 64 bit, io non ho ancora dato uno sguardo all’ultima versione che è già online ma la devono ancora completare, però avevo sentito da qualche parte che ne uscirà una per i 64 bit. Per linux invece c’è GDB: The GNU Project Debugger il link è questo:
http://www.gnu.org/s/gdb/
E’ molto buono come debugger.
Per divivoma:
Allora con OllyDbg purtroppo non si può debuggare direttamente un’altro PC via seriale o via ethernet, come non si può debuggare neanche windows phone, per fare questo esiste un programma che è un disassembler, se non sai la differenza te la spiego ora:
Debugger: Con esso puoi scorrere e seguire il flusso di un programma
Disassembler: Ti mostra unicamente il codice assembly senza la possibilità di eseguire il programma passo passo come con il debugger
Per fare ad esempio le cose che hai citato prima, ti serve IDA Disassembler, che però ha un unico difettuccio costa la bellezza di 700 euro e passa, esiste anche una versione demo di questo programma scaricaribile e dura 30 giorni, ma come versione demo è pessima perché puoi solo disassemblare solo file exe e dll,invece con la versione completa ti disassembla pure la macchinette del caffè 😉 per quel che mi riguarda è il miglior disassembler esistente, io ci faccio di tutto con questo programma.
Se ti interessa ida disassembler lo trovi qui:
http://www.hex-rays.com/idapro/
E un programma spettacolare, ti disassembla tutto a flow chart quindi è molto facile da seguire
Comunque sia per quanto riguarda windows phone non so cosa intendi, in qualsiasi caso IDA ti permette di disassemblare il firmware e i programmi, ovviamente per quanto riguarda la modifica del firmware devi prima fare il dump di esso sul pc, ha anche al suo interno un debugger ma non è come quello di OllyDbg. Visto che sei interessato a queste cose, hack ecc…, sto preparando da un po’ di giorni un paio di articoletti in merito all’argomento che son sicuro apprezzerete, ma non parlo ancora lascio la sorpresa 😉 comunque nulla di complesso, è giusto per farvi vedere questa meravigliosa arte. Da quando l’ho conosciuta e come una malattia e presto mi sposterò sul reversing di tablet, modem adsl, console e via dicendo.
Per quanto riguarda la tua domanda in merito se puoi o no vedere unicamente una funzione all’interno del tuo main è ovviamente si, le chiamate a delle funzioni vengono richiamate in assembly con una call, ovviamente per poterla vedere devi seguire il flusso del tuo programma dall’inizio fino alla chiamata della tua funzione, una volta che sei a quella call steppi all’interno della tua funzione con F7 e vedi tutto il listato assembly, e piu semplice farlo che dirlo fidati, io ho impiegato un po’ prima di imparare bene a capire l’assembly ma una volta che hai i concetti base ti viene tutto piu semplice e lineare.
perfetto…preciso e conciso 😉 grazie..
ad ogni modo a questo p.to sinceramente dico che a parità di costo e di funzionalità direi che il GDB è nettamente superiore al debugger OllyDbg..
Costo ovviamente zero per entrambi, funzionalità per quanto mi hai detto, il gdb presenta diverse versioni ad esempio il kgdboe (over ethernet) e anche quello su seriale..Kgdboc se non erro..over console..
Ti facevo queste domande perchè è proprio quello che ho fatto con linux, ti spiego meglio..
Da host pc ho installato il kgdboe come modulo..OS Wind River..siamo in real time..
Dopodiche ho configurato il modulo sul target in modo da farlo comunicare con il pc host..non è difficile basta essere un pò esperti con ifconfig e porte ..
Dopodichè inizia il divertimento..puoi debuggare tutto il kernel..ovviamente mettendo degl’entrypoint da Host all’interno del vmlinux…ossia il file contenente tutte le varie chiamate a sistema..quindi essenzialmente conoscendo gl’entry point in cui devi agire (e quindi conoscendo com’è fatto ad esempio un modulo che vuoi debuggare), fai partire il flusso del programma…
Gdb ti permette non solo di fermarti all’entry point, e il codice lo puoi visualizzare sia in c che in assembler..e su questo siamo pari..
ad ogni modo credo che il fatto di poter utilizzare il debugger su target connesso ad host o via seriale o via ethernet renda questo debugger estremamente versatile e potente…
Qundi se ho capito bene, in un certo senso gdb può funzionare anche da disassembler ammesso che tu abbia i permessi di root anche sulla macchina host…
Domanda.. a questo p.to cos’è che puoi fare con il disassembler che con il gdb non puoi fare? di primo “acchitto” penso che forse con il disass. puoi connetterti fisicamente sugli indirizzi di memoria e leggere i comandi che il processore sta dando e tradurli in assembler giusto…? fammi notare un pò la differenza sostanziale 😉
ciao e grazie
Ciao,
non ho ben capito la tua domanda finale sinceramente, proverò a rispondere comunque per come ho capito io, se poi mi sono sbagliato correggimi.
In pratica un debugger oltre a permetterti di far avanzare istruzione dopo istruzione, con gli step, il tuo programma target, facendoti vedere come cambiano i valori nei vari registri della CPU e i vari dati che vengono passati, ti mostra anche nello stesso tempo il listato del codice sorgente disassemblato in assembly, unito a delle utili informazioni che ti mostrano ad esempio come è stata strutturata una determinata API del programma.
Il problema e che usando un debugger qualunque, tutto il codice disassemblato viene mostrato come un normale testo istruzione dopo istruzione, vedi GDB o Olly, se invece noi apriamo lo stesso programma con IDA Disassembler, credo che quando scrivi disassembler intendi IDA, noi vediamo si l’intero codice assembly ma non scritto istruzione dopo istruzione come in un debugger, ma con dei flow chart che rende molto piu semplice la lettura e la comprensione del programma. Prova a cercare qualche immagine di IDA Disassembler e vedi subito come è più semplice una lettura in quel modo che non come con un debugger. Ovviamente il debugger è nato per poter inserire dei breakpoint normali o hardware, modificare e leggere i dati presenti nei registri e modificare le istruzioni che incontri per vedere come si comporta il programma in base alle modifiche effettuate, vedi ad esempio se devi craccare un programma semplice che ti richiede una password, ti basta modificare un salto jump e lo puoi fare tranquillamente con Olly e poi avviare il programma x vedere cosa capita e se il programma si registra tranquillamente. Per quanto riguarda gli indirizzi di memoria, ad ogni istruzione vengono modificati e li puoi leggere e modificare a tuo piacimento in un debugger come Olly, sono posti in alto a destra. Spero di aver risposto alla tua domanda
diciamo che io sono andato un pò oltre il vero e proprio debugger pensandoci…infatti ho detto che pensavo che l’IDA ti permetteva addirittura di andare a leggere gli indirizzi di memoria sul dispositivo vero e proprio…ma ovviamente questo lo puoi fare soltanto con un analizzatore di stati logici..immaginati che accoppiata vincente analizzatore ed IDA…mi sa che è cosi che si craccano i nuovi video games che escono..(ovviamente con l’aiuto di qualcuno dall’interno ..ma lasciamo perdere 🙂 )..
Dopo questa perplessità chiarita, penso di aver afferrato il concetto..il disassembler ti mostra il FLUSSO e non solo il codice…e soprattutto lo fa in maniera ordinata e sequenziale…si questo si che è un bel aiuto ! però guarda..a dirti il vero..(lo so sono cm san tommaso 🙂 )…vorrei vederli a confronto…gdb e IDA..e magari vedere in realtà cosa riesce a fare l’uno piu dell’altro..oltre al tempo che ci si mette a debbuggare con uno rispetto che con l’altro..
Magari organizziamo qualche prova… io il gdb c e l ho già pronto 😉
l’Ida lo hai tu… 🙂
ciao
Perfetto hai afferrato in pieno il concetto, menomale che avevo capito bene la tua domanda 😉 ,comunque sia GDB so che è anch’ esso un ottimo debugger, ma non essendo molto amante di linux non gli ho mai dato un occhiata, so che per esempio l’iPad e l’iPhone li colleghi al pc e li debuggi con gdb, suppongo la stessa cosa per Windows Phone, visto che me ne parlavi prima.
Per quanto riguarda i video games, non credo nell’aiuto di qualcuno dall’interno perché non sarebbe necessario, io ad esempio non mi ci metterei mai a reversare una cosa del genere, il motivo è semplice, ormai tutti gli sviluppatori di software e giochi non hanno piu inventiva per quanto riguarda le protezioni, nel senso che ti proteggono un programma con una sola protezione ripetuta un centinaio di volte, ti faccio un esempio prendi autocad o robe simili, utilizzano diversi layer con le stesse protezioni ripetute centinaia di volte, quindi ormai non è piu divertente, tolto il primo layer si tratta di fare come i robot, perché tutti gli altri layer sono uguali con la stessa protezione trovata prima e quindi diventa monotono e ripetitivo…
Dove invece ti diverti seriamente, e nell’estrarre i firmware dai vari dispositivi tipo cellulari, tablet ecc…
Per quanto riguarda la prova accetto 😉
come mai non sei molto amante di linux…? neanche io lo ero prima..poi pian piano la sua semplicità e apertura mentale alla condivisione…mi hanno convinto ad usarlo al 99% del mio tempo sul pc…l’1% uso windows se proprio devo aprire qlk programma che avevo installato su tale partizione…tipo LabView o SPICE…ma sto cercando versioni di spice anche per linux..tipo geda…
PS: io ti consiglio di passare a linux 🙂
Ciao
Conosco giusto le basi di linux, l’ho usato per qualche mese, solo che usando tutti programmi per Windows molte volte non è stato comodo, ho usato ovviamente anche gli emulatori, ma non tutti i programmi funzionano correttamente, l’unica cosa che ora ho intenzione di fare, visto che voglio passare al reversing di dispositivi cellulari, ipod e quant’altro, e quello di caricare sia linux che windows sull’hard disk, visto che linux si presta molto bene in queste cose rispetto windows, poi be se fai reversing unicamente del software, la maggior parte delle cose che trovi online sono tutte per windows. Giusto per sapere, io avevo intenzione di montare ubuntu, tu cosa ne pensi?Che linux hai?
si penso che ubuntu va bene..soprattutto se devi iniziare quasi da zero..l’unica differenza che ha da fedora è che devi aggiornarlo più spesso (praticamente devi stare più al passo con la community..)..
Infatti se vedi, da poco si è passati alla versione 3.0 del kernel linux…e gli aggiornamenti al kernel non smettono mai di essere fatti e rifatti credimi!
Ad ogni modo se devi usarlo soltanto per alcune cose non ti preoccupare prendi Ubuntu 10.0 e tieniti il kernel che scarichi e che troverai già nel download di Ubuntu..
Poi ovviamente dovrai pian piano entrare nel meccanismo dell’installazione dei vari pacchetti che ti servono ogni volta che dovrai fare qualcosa ..ad esempio gdb dovrebbe già esserci…Kgdb non saprei…ke non è la stessa cosa di gdb poichè opera in Kernel space..ma cmq una cosa alla volta.. anch’io sono ancora all’inizio ma ho la fortuna di lavorare con un paio di mostri che conoscono linux sin dalla nascita 😉
cmq siam sempre qui per dare na mano!
Per sfizio…cerca dm-ioband oppure Cgroups..ci sto lavorando adesso..guarda cosa si riesce a fare cn linux…se dovess fare queste cose con windows…nn saprei da dove cominciare ne dove cercare (ad esempio l’allocazione della banda in base hai processi task..), carino no?
ciao
Che bei ricordi,
tempi passati dove usavo questo programma per ore e ore.
è un ottimo programma
ma attualmente è necessario precisare che questo tipo dubugger viene utilizzato quasi esclusivamente per la scrittura di CracK o KeyGen visto che ultimamente la programmazione direttamente in assemblea è piuttosto inesistente.
gli ultimi programmi che erano fattidirettamente in assemblea erano i compilatori e il kernel,
ma anche questo mondo c’è stata una rivoluzionedei linguaggi di alto livello ad esempio il kernel linux viene scritto direttamente in linguaggio C e perfino il compilatore gcc c’è un compilatore in linguaggio C. anche lui stesso è stato a lui è stato compilato con se stesso in linguaggio di alto livello.
Comunque è sempre interessante vedere il funzionamento di un programma all’interno,
O come il sistema operativo assegna le risorse di memoria.
analizzatore di stati logici si usa moltissimo dove non è possibile fare analizzare il codice sorgente di un programma per diverse ragioni.
prima di tutto che il programma è incapsulato in un dispositivo dove non può essere estratto,
l’esempio tipico sono in smar card dove gli viene incapsulato tutto su un singolo chip e non è possibile smontarlo o accedersi al EEPROM dove viene contenuto programma quindi l’unico attacco possibile è analizzando il dialogo tra tra il lettore e la smar card,
Questo attacco di solito è piuttosto poco efficace.
è per questo che tanti scelgono di tenerli i dati citati o sensibili tipo accessi ha delle reti come il cellulare ritenendo i dati riservati sulla sim e uscendoli solo criptati.
e per lo stesso motivo che viene utilizzatodelle smar card per la pey TV come SKY.
È forse da constatare che un metodo molto efficace visto che dopo sei anni di utilizzo di questo sistema di codifica non è stato ancora bucato.
Visto che non è possibile leggere le chiavi master su EEPROM come era stato fatto all’epoca SECA.
È questo poco poco diventa oasi sempre più difficile visto che la tecnologia della semiconduttori scende in dimensione 90 nm non è più possibile inserire degli atti direttamente sul chip per rilevare segnali a differenza di cosa si era fatto sulla tecnologia 1 µm che ancora possibile inserire degli aghi per analizzare i diversi segnali.
Anch’io con il tempo a poco a poco migrato su piattaforma linux in particolar modo l’unica distribuzione decente Ubuntu, intendo con una comunità che è molto disponibile ad aiutarti in caso di problemi e che non si ritiene di casta superiore per chi utilizza linux, quindi è come nuovo utente di soffrire per capire come funziona.
Ha avuto ubuntu l’obiettivo di essere alla portata di tutti,
Ha semplificato quasi tutte le operazioni di manutenzione rendendole facile e intuitivo.
Per me l’unico grosso vincolo e l’accessibilità al sistema per i diversamente abili.
il supporto alla sintesi vocale è inesistente o molto difficile da far funzionare.
il riconoscimento vocale non esiste per nulla.
sono allo stesso livello del sistema operativo Apple dove queste cose non esistono o non sono difficile da far funzionare.
Windows è l’unico sistema operativo che si è occupato dell’accessibilità per i diversamente abili.
Reingegnerizzazione dei firmware è una pratica che questi ultimi tempi è stato molto sviluppata,
semplicemente ho visto che alcune router ADSL tipo quello di Alice, questo metodo è stato aggiunto delle funzionalità molto avanzate di tipo OpenVPN.
Ma in realtà quella che fa più gola della reverse engineering è quella dei ricevitore satellitare di SKY,
così da poter bucare le codifiche.
Mi ricorda una lontana epoca all’epoca SECA dove si scaricava il contenuto della RAM attraverso un’interfaccia JTAG così da poter recuperare i codici che codificano i canali, che belli ricordi della scuola superiore, dopo non potevano dire che non facevamo nulla nei laboratori di elettronica.
si oltre tutto bisogna anche dire che l’analizzatore di stati logici costa un bel pò…quindi seppure si volesse utilizzare proprio quello all’ultimo grido…bisogna andare oltre i 100 mila € !!
Se è come dici allora quando c era tele piu al posto di sky (o anche Stream ve lo ricordate??) si riuscivano a clonare benissmimo le smart card proprio per i motivi che dicevi..quindi è un problema di accesso alle eeprom ho capito bene?
Per quanto riguarda la crittografia..credo oggi vengano usati i cosiddetti turbocodici e quindi la vedo un pò dura decifrarli…m pare chiavi addirittura a 128 bit o robe del genere…altro che WPA2 :)..!
Comunque resta sempre un mondo affascinante quello della crittografia..ma soprattutto quello di chi la sfida… 😉
su questo andrò ad indagare sicuramente..e appena trovo qualcosa che non va o che è stato messo da parte per troppo tempo, faccio un bel “cazziatone” a chi si occupa di ciò..per quanto possa contare la mia opinione nella community come sviluppatore…cmq ti farò sapere…anzi se mi dici che applicazioni ci sono su Ubuntu per i diversamenti abili facciamo prima..cosi magari vedo un pò su quali moduli gettano le loro basi 😉
fammi sapere fabry
Quel era l’epoca benedetta dovevo era appassionato di codifica e di cifratura,
avevano organizzato i pomeriggi dei lavoratori dopo scuola dove si facevano queste cose completamente clandestinamente.
per hack una smart card all’epoca avevano fatto con una dell’autobus,
prima di tutto avevano tolto tutta la plastica per mettere a nudo il chip,
Dopo abbiamo preso il microscopio del laboratorio di biologia visto che all’epoca si potevano ancora vedere le piste sul circuito integrato visto le dimensione chilometriche delle piste, allora attuale non è nemmeno pensabile con la tecnologia 90 nm è necessario usare un microscopio elettronico che sicuramente non abbiamo scuola.
dopo con degli aghi insulina all’epoca avevamo un po’ di difficoltà ripieni, ma oggi ne ho quantità pazzesche visto che l’uso di giorni.
Con questi agli all’insulina ci siamo connessi sul bus che connetteva il microcontrollori al EEPROM e potevamo leggere con un circuito molto semplice connesso ad un computer tramite RS 232.
Vedevamo il dialogo tra i due e potevamo intercettare qualsiasi stringa di dati inviati.
All’epoca del SECA 1 che all’inizio usava Tele+ o Stream, La chiave CW1 CW2 veniva cambiata una volta Alla settimana se non di più.
quindi bastava creare una smacchia che quando viene interrogato dalla CW1 E CW2 memorizzata dentro senza nessuna elaborazione successiva.
dopo si è passato SECA 2 gli ha incominciato a diventare sempre più difficile visto che le chiave cambiavano ogni 10 secondi come attualmente succede con sky ma l’algoritmo era facile da squalificare i mezzi all’epoca erano sufficienti per squalificare questa chiave.
attualmente NDS perfino il ricevitore fa parte della codifica e la scheda da sola non è sufficiente per bucare la codifica ma è necessario una specie di alchimia tra i due.
Dopo è necessario precisare che ci sono stati interessi economici,
a una certa epoca la pirateria del SECA2 è stato molto utile per togliersi il contratto l’azienda che produceva dove sky doveva essere ancora legata i 10 anni successivi, ma come sky voleva usare esclusivamente la sua codifica NDS sicuramente c’è stato molte aiuti dalla loro parte che fosse così facile piantare le schede
Attualmente per WPA2 esistono dei programmi molto efficaci che per svolgere la quantità di calcoli astronomici richiesti per rompere questa codifica usando la forza bruta usano i processori delle schede video che sono diventati molto più potenti per effettuare operazioni in parallele.
E nella stessa ottica da vecchio codifica DES può essere aperta usando un computer formato esclusivamente FPGA perché molto adatte al calcolo parallelo.
Al di là di tutte le considerazioni fatte da te giustamente.. è vero oggi è difficile utilizzare le stesse tecniche che usavi allora…poi i chip vengono anche completamente immersi in una “bolla” in modo tale da non poter vedere i connettori..quindi..che dire..per fortuna che c e lo streaming e i dream box 🙂
sai cosa sono no? penso di si..
con essi si riesce a “condividere” via internet un solo abbonamento criptato…non so se ne hai mai sentito parlare…cmq ci sono già da un bel pò..mi sa 5 6 anni.. costano un bel pò quelli buoni..poi ovviamente ci saranno altri vincoli..e inoltre credo sia illegale come sistema di sharing degli abbonamenti.. 🙂
Guarda qui ad esempio ho trovato come si può sharare un video su vlc..e farlo vedere su dreambox…
http://www.techwatch.co.uk/forums/34410-streaming-avi-films-from-pc-to-dreambox-tv.html
se si può fare questo.. e addirittura con l’xbox..utilizzando la scheda Da Vinci mi pare di freescale..che monta uno degl’ultimi multimedial processor..
http://www.dreambox.it/guide_dream_in_streamin_con_xbox.htm
In conclusione diciamo che..un modo per sconfiggere o raggirare la crittografia lo si troverà sempre…e a noi può star bene o meno..che sia legale o no…un robin hood ci sarà sempre…!
Cosa ne pensate del dream box..? l’hai provato o consoci qualcuno che lo ha utilizzato..in realtà io volevo comprarlo all’inizio però poi sono stato abbastanza titubante perchè quando lo vidi non mi sembrava una tecnologia “matura” per modo di dire..ma adesso dovrei ricredermi non pensi..?
ciao
comunque siamo passati da un semplice debugger..a tirar fuori metodologie di anti-crittografia… non vorrei continuare a dilinguarmi altrimenti finiamo fuori tema..se vuoi apriamo un post..o meglio ancora visto che sei più esperto di me potresti scriverci un articoletto che ne pensi?
ciao
Ho aperto una discussione sul forum,
Così possiamo continuare a discutere di codifiche,
e di che modo aggirarli
http://it.emcelettronica.com/forum/codifica-satellitare
Per divivoma:
Ho cercato quello che mi dicevi: dm – ioband e Cgroups, sono molto interessanti come progetti, dopo questo mi hai convinto ha montare linux Ubuntu comunque, ovviamente insieme a Windows, purtroppo non riesco a staccarmi dalla sua interfaccia grafica, sarà che perché sono cresciuto con questo sistema 😉
Per Fabrizio87:
Non riesco sinceramente a capire le tue affermazioni e dove le hai lette, è vero che ormai si usa “solo” più il C, per quel che ne so ad esempio l’assembly (non assembler, che è il compilatore per assembly) è utilizzato per fare le rifiniture dei software, giochi e scrivere firmware per le schede grafiche, modem e via dicendo, quindi non è che è così tanto in disuso, comunque sia Olly non è usato solo per Crack, keygen e reversing, ma anche per trovare i bug in un qualsiasi tipo di software che non sia scritto in linguaggio .net oppure per x64.
Nel caso presente si tiene conto di altre architetture come firmware Le cose cambiano un po’ chino,
gli il linguaggio assembler ancora un po’ di senso, visto che in questo caso devi ottimizzare le poche risorse a disposizione o devi esportare il massimo della potenza a disposizione,
quindi non ti puoi fidare al 100% di un compilatore di compiere in alto livello ma questo vale solo nel caso di architetture di tipo ARM, mips o qualunque altra.
nel caso di programmi dove c’è una grande influenza dell’interfaccia grafica si fa ricorso a distanza di programmazione ad esempio .NET Framework e librerie software tipo DirectX.
In questi casi viene fatta una compilazione a vari livelli, fino a ottenere il codice macchina.
Falloide paga di tale codice mi sembra piuttosto una cosa ardua,
in alcuni casi di certi bug non sarà nemmeno possibile correggerli visto che si rivelano su diverse librerie di tipo DirectX o .NET Framework che non puoi nemmeno correggere.
tutto questo si intende se uno fa programmazione commerciale, per intenderci se il prodotto sarà venduto dove non puoi modificare le librerie di terzi.
quindi la questione molto più articolata soprattutto quanto il programma deve essere commercializzato.
Diciamoci certamente,
Scrivere un programma direttamente linguaggio assembly,
per realizzare un’interfaccia grafica funzionante X68 ci vuole un’infinità di righe da scoraggiare qualsiasi programmatore e per di più è necessario avere una conoscenza profonda del funzionamento del sistema operativo Windows per dialogare direttamente con i diversi periferiche.
In C con un numero ridotto di istruzione fa la stessa cosa.
Anch’io nel passato ero nell’idea di scrivere tutte senza usare librerie esterne,
ad esempio avevo scritto un programma che creava di PDF,
Mi sono reso conto che il tempo utilizzato persino questo programma e solo il motore PDF se l’avrei dedicato a scrivere il programma nella parte che non esistevano librerie il mio prodotto sarebbe stato molto meglio e molto più efficace che sprecare il mio tempo a scrivere funzioni di base
non mi sono mai trovato nella condizione di dover analizzare il codice sorgente di un programma, ma credo, che sia interessante dal punto di vista informatico, vedere anche come è strutturato, come il programma conversa con l’architettura della macchina, dato che si sta visualizzando un codice ASSEMBLY, e non un linguaggio ad alto livello come il Basic o dirittura il C++, certo è che comunque si possono analizzare anche i programmi propri, per vedere se dovremmo fare delle modifiche per gestire meglio la memoria, o quant’altro!
per questa ultima cosa che dici tu..ci vengono incontro dei tools che si potrebbero accostare al vero e proprio debugger.. si chiamano tool di profiling come ad esempio il gprof ;)…dai un occhiata in giro 😉 poi magari si approfondisce..ciao