L’incontro è aperto a tutti e gratuito, alle 21:00 allo Spazio Polaresco di Longuelo.

Per maggiori informazioni rimando al blog dei CodeLovers.

A presto!

Riassunto delle puntate precedenti

Ecco la ricetta per “leggere” il CAPTCHA di Vodafone!

• rimuovere il rumore dal fondo dell’immagine, per sottrazione con un’immagine di solo rumore ottenuta comparando molti CAPTCHA;
• applicare un filtro a soglia per rendere netti i contorni dei caratteri;
• opzionalmente, correggere le aree bianche o nere troppo piccole e (semi)isolate dal resto;
• segmentare l’immagine nei vari caratteri, ad esempio con un algoritmo flood fill;
• ridimensionare ogni lettera individuata a 15×15 pixel;
• dare in pasto ogni carattere a una rete neurale a percettrone propriamente allenata.

Ciò detto, quale è l’accuratezza del sistema?

Risultati

Ho testato un’implementazione dell’algoritmo di cui sopra e i risultati sono stati i seguenti:

1. il CAPTCHA viene decodificato correttamente al primo tentativo in più del 90% dei casi su un campione di circa 100 immagini;
2. come spiegato nella parte 4 questo dato si riferisce a prove fatte su un campione di immagini diverse da quelle usate per l’allenamento della rete neurale (cross-validation), quindi la percentuale del 90% è rappresentativa dell’accuratezza reale;
3. ovviamente, se la decodifica non funziona al primo colpo si può ritentare. Visto che basta un solo tentativo a buon fine per rompere la protezione fornita dal CAPTCHA, la probabilità di successo nella pratica è ancora più alta: con con 3 tentativi si sbaglia su una sola lettura su mille, e con 6 tentativi una su un milione!

Note statistiche: nella ragionevolissima ipotesi che gli esiti delle letture di CAPTCHA siano indipendenti, segue che i risultati del punto 1 sono sufficienti per affermare che la percentuale di successo è sopra al 90% con significatività del 99%. Quanto descritto al punto 3 discende dalla stessa ipotesi, in quanto la probabilità P di successo complessiva è data da

P = 1-[(1-p)(1-p)(1-p)...] n volte

dove p è la probabilità di successo del singolo tentativo ed n il numero di tentativi.

Tecniche implementative

Nota Bene: i prossimi paragrafi sono dedicati ai programmatori ed alle persone con esperienza in ambito informatico – è normale che non risulti di facile comprensione agli altri lettori.

Come si possono tradurre in pratica le idee esposte fino a questo punto? Io ho usato questi strumenti:

• il linguaggio di programmazione Scala;
• l’ambiente di sviluppo Eclipse con il plugin Scala-IDE;
• il motore di reti neurali Encog;
• GIMP e (ugh!) LibreOffice Calc per alcune prove e prototipi.

Scala

Il linguaggio Scala è stato scelto per due ragioni:

1. è molto, molto compatibile con Java, permettendo in particolare di utilizzare librerie e classi Java esistenti. Naturalmente questo fa molto comodo per usare Encog, che è scritto proprio in Java!
2. rispetto a Java ha alcune caratteristiche interessanti, che se ben usate portano produrre a codice, a mio parere, molto più compatto e leggibile.

Ad esempio, è possibile definire classi i cui oggetti si usano come i vettori. Sembra inutile? Si pensi a come semplifica la vita poter scrivere codice come questo in una libreria che fa trattamento di immagini:

if (image(2, 3) == BLACK)){
    image(2, 3) = WHITE
}

Sfido qualunque programmatore a non capire il significato! E’ interessante anche notare che, per raggiungere questo risultato, non c’è bisogno di sintassi astruse, basta infatti definire due metodi particolari, apply ed update, come nell’esempio che segue:

class Image(...) {
    def apply(x:Int, y:Int):Int = {
        // ritorna in un intero il colore alla posizione (x,y)
    }
    def update(x:Int, y:Int, color:Int):Unit = {
        // cambia in color il colore del pixel alla posizione (x,y)
    }
}

Ancora una volta, a mio parere, estremamente leggibile. Ho usato codice di questo tipo per costruire un wrapper attorno a java.awt.Image, la classe Java per la gestione delle immagini, ottenendo una classe allo stesso tempo potente e semplice, in poche righe di codice.

Un’altra chicca simile è la possibilità di definire metodi con nomi strani, ad esempio +, - oppure |, ridefinendo in pratica gli operatori del linguaggio per classi specifiche. Ho usato questa particolarità per implementare i filtri delle immagini con una sintassi simile a quella delle shell Unix.

Credo che sia immediato capire il senso di questo codice:

image = read(new FileInputStream(file))
filteredImage = image | new DesaturateFilter() | new RemovePatternFilter(new FileInputStream("data/pattern.png")) | new ThresholdFilter(170) | ...

Per poter scrivere la riga di cui sopra basta implementare il metodo | di Image e definire una “classe astratta” che rappresenti un filtro:

class Image(...) {
  def |(filter:ImageFilter):Image = {
    filter.filter(this)
  }
}

trait ImageFilter {
  def filter(image:Image):Image
}

E’ da notare come in Scala è possibile usare semplici spazi al posto dell’operatore “.” tipico di Java, e si possano anche omettere le parentesi ove non ambiguo, e questo permette di scrivere

filteredImage = image | filter

al posto di

filteredImage = image.|(filter)

A mio parere, un vero colpo di genio! Scegliendo nomi appropriati per i metodi, infatti, questa caratteristica da sola porta a scrivere codice molto più simile al linguaggio naturale, quindi facile da comprendere, rispetto alle controparti Java. Altri esempi illuminanti:

count = collection size
heightInPixels = image height
calculator compute inputs

In questi esempi si sarà notato che sono omessi anche i terminatori di riga (“;” in Java). Questo è l’ennesimo piccolo beneficio di Scala: i terminatori si possono omettere ovunque non sia ambiguo. Perchè consumare tasti inutilmente?

Un’altro aspetto che mi piace molto di Scala è che nonostante sia un linguaggio staticamente tipato (come Java e a differenza di Groovy, Ruby o Python) non costringe ad usare sintassi prolissa per specificare i tipi degli oggetti ovunque. Mi spiego: supponendo di avere un metodo che accetta un oggetto Car e poi lo usa, in Java occorre scrivere qualcosa del tipo:

Brick demolish(Car car){
  Car myCar = car;
  return myCar.demolish();
}

In questo esempio, i tipi in grassetto non sono strettamente necessari: è evidente che myCar debba essere di tipo Car (poichè car è di tipo Car), analogamente dal momento che il metodo ritorna sempre e solo il risultato di Car.demolish() è ovvio che il risultato sia un’istanza di Brick. In Scala, dal momento che tutto questo è superfluo, può essere omesso:

def demolish(car:Car){
  val myCar = car;
  return myCar demolish
}

Il compilatore controlla tutti i tipi e completa le definizioni ovunque possibile, il che risparmia un bel po’ di digitazioni inutili (e facili da sbagliare). Ovviamente in caso di ambiguità ci sarà una segnalazione di errore, solo in quel caso sarà necessario specificare i tipi come in Java. L’aspetto interessante è che si arriva a scritture concise simili a quelle dei linguaggi tipati dinamicamente senza rinunciare agli utili controlli di coerenza del compilatore.

Encog

L’uso di Encog di per sè non è particolarmente bizzarro, nel senso che segue esattamente l’interfaccia Java documentata sul sito ufficiale. Ad esempio, questo è il codice per caricare una rete neurale allenata con l’Encog Workbench:

network = new BasicNetworkPersistor().load(new ReadXML(new FileInputStream("model.eg"))).asInstanceOf[BasicNetwork]

L’unica cosa degna di nota è l’ultima parte, asInstanceOf[BasicNetwork], che è l’equivalente di un cast in Java richiesto dal fatto che BasicNetworkPersistor.load() ritorna un EncogPersistedObject che è una sopraclasse di BasicNetwork. L’uso della rete vera e propria è addirittura banale:

inputs = new BasicNeuralData(rawInputs toArray)
outputs = network compute inputs

dove rawInputs non è che una List[Double].

Ecco il codice!

Viste le tecniche principali ed alcune curiosità sulla stesura del codice non resta, per chi ha ancora voglia di studiare, che prendere in mano il codice sorgente del programma!

Scarica il Progetto Eclipse per la decodifica dei CAPTCHA (zip, 1MB)

Il progetto contiene:

• la cartella training che contiene un sufficiente numero di CAPTCHA scaricati e decodificati manualmente per l’allenamento;
• il package net.moioli.moiosms.imagefilters contenente le implementazioni in Scala dei filtri grafici descritti nelle puntate precedenti;
• il package net.moioli.moiosms.training contenente:
  • il programma TrainingImagePreparer che prende i CAPTCHA nella cartella training, applica i filtri grafici e li scompone in singole lettere divise per allenamento e validazione;
  • il programma TrainingCsvGenerator che, prendendo le lettere generate dal programma precedente, crea file CSV che possono essere importati in Encog Workbench;
• data/letters.eg, un esempio di rete Encog già allenata in questo modo e soprattutto
• OCRTester, un programma che legge effettivamente i CAPTCHA come descritto in questi articoli!

Il modo più semplice per provare tutto questo è:

1. installare l’ultima versione di Eclipse per Java;
2. installare il plugin Scala-IDE, che contiene il compilatore Scala;
3. decomprimere lo zip;
4. importare il progetto (menù File, Import…, General, Existing Project into Workspace);
5. lanciare uno dei programmi con la voce Run as… Scala Application dal menù che compare cliccando con il tasto destro sul file corrispondente.

Dovreste ritrovarvi con una schermata simile alla seguente:

Conclusioni

Con questo articolo chiudo la serie sui CAPTCHA iniziata qualche mese fa. So che non è molto rispetto alla fine del progetto MoioSMS ma spero possa essere un adeguato punto di ripartenza per chi volesse ricominciarlo o semplicemente ampliare le proprie conoscenze. Scrivete pure nei commenti opinioni e domande!

Normalizzazione delle dimensioni delle lettere

Come si nota dall’immagine seguente, nel CAPTCHA di Vodafone solitamente le lettere  sono di dimensioni diverse.

Questo è chiaramente un meccanismo per rendere più difficile l’individuazione delle lettere – peccato che è anche particolarmente semplice da aggirare. Vediamo come.

Il primo passo è di calcolare il rettangolo minimo che contiene ogni lettera. Il procedimento è semplicissimo: basta individuare le coordinate minime e massime per ogni colore. Graficamente è possibile rappresentare il procedimento come segue:

A questo punto, senza neanche troppa fatica, normalizzare le immagini delle singole lettere significa semplicemente ridimensionarle tutte a una stessa grandezza fissata, in questo come 15×15.

Fatto il ridimensionamento, voilà, le distorsioni delle lettere sono praticamente sparite!

Il ridimensionamento è una funzione presente in qualunque libreria di manipolazione delle immagini, quindi non entro nemmeno nei dettagli dei possibili algoritmi.

Dopo aver rimosso il rumore all’immagine, segmentato i singoli caratteri ed averli normalizzati, siamo finalmente pronti per il riconoscimento vero e proprio.

Riconoscimento: prima la teoria…

Premessa: mi spiace per il titolo un po’ deprimente, ma proprio non riesco a spiegare questo argomento diversamente! I paragrafi seguenti richiedono un minimo di conoscenze matematiche, in particolare sul concetto di funzione, che è meglio aver compreso prima di gettarsi nella lettura della parte che segue.

Il problema del riconoscimento si può porre così: possiamo costruire una funzione matematica f che, dati in input i valori dei pixel che compongono l’immagine, produca in output la lettera rappresentata?

Dettaglio matematico: in modo un po’ più rigoroso il problema è:

definire una funzione y=f(x), dove:

x è un vettore di 225 numeri (corrispondenti a 15×15 pixel) tra 0 (bianco) ed 1 (nero)

y è un vettore di 34 numeri tra 0 ed 1 (uno per ogni carattere che può comparire nel CAPTCHA) e

y_i vale 1 se x rappresenta il carattere i e 0 altrimenti

Se siete arrivati fino a questo punto, dovreste avere una domanda in testa: come è possibile definire un mostro di funzione come questo?

Una possibilità è di spendere qualche mese ragionando su come definire analiticamente la funzione f, cosa non particolarmente comoda, in particolare a causa del gran numero di variabili in ingresso. Una via più conveniente, e decisamente più furba, è usare le reti neurali, che possiamo definire molto grossolanamente come “funzioni imitatrici“.

Al di là del nome esotico, le reti neurali non sono altro che funzioni matematiche, con la particolarità che sono in grado di “imitare” (approssimando) altre funzioni. La cosa divertente è che le funzioni imitate possono anche essere ignote!

Nel nostro caso, possiamo ipotizzare senza troppa fantasia che una funzione f esista; non sapendola scrivere ci limitiamo ad imitarla con una rete neurale!

Dettaglio matematico: in modo un po’ più preciso, ed in estrema sintesi, una rete neurale è una funzione parametrica che a seconda dei valori assunti dai suoi parametri può approssimare una qualunque altra funzione (non necessariamente nota). Esiste un simpatico teorema il quale prova che una particolare classe di reti neurali, le reti a percettrone con strato nascosto singolo, possono approssimare con arbitraria precisione arbitrarie funzioni, sotto ipotesi molto permissive e certamente verificate qui. Ovviamente, ci concentreremo su questo particolare tipo di rete nel seguito dell’articolo.

Incredibile… Ma funziona!

Come è possibile che una rete neurale possa approssimare la sfuggente funzione f, che non abbiamo mai visto?

L’idea è che la rete è in grado di apprendere da alcuni esempi che gli vengono forniti.

Si può infatti “esporre” un insieme di input ed output preparati a mano ad una rete neurale ed aspettarsi che questa “impari per esempi” come funzionare. Una volta terminato questo allenamento, la rete dovrebbe essere in grado di calcolare dei “buoni output” anche a partire da input nuovi.

Sembra incredibile? Eppure funziona!

Infatti, non è un caso che attualmente tutti i migliori software OCR facciano esattamente così. Ricordo tra gli altri tesseract, il software usato da Google per la scansione dei libri in Google Books.

Per l’allenamento è necessario, innanzitutto, preparare un bel po’ di caratteri e dividerli per lettera a mano. In questo modo avremo un certo insieme di coppie input-output da dare in pasto alla rete durante l’allenamento. Personalmente ci ho messo diverso tempo, il risultato è qualcosa di questo genere:

Poi occorre procurarsi un’implementazione degli algoritmi delle reti neurali che, in particolare, permetta l’allenamento. Esistono ottimi “motori di reti neurali” già fatti che fortunatamente permettono di evitare un bel po’ di complessità numeriche.

Nota tecnica: calcolare l’output di una rete neurale, in particolare di una rete a percettrone con strato singolo nascosto come quelle usate qui, è un gioco da ragazzi, si tratta infatti di poco più di addizioni e prodotti per costanti. L’allenamento, invece, è un processo ripetititivo abbastanza complesso, soprattutto se si tiene conto delle problematiche di efficienza – ecco perchè è utile trovare un motore “chiavi in mano”.

Io ho scelto Encog, che ho trovato veramente ottimo. Tra le altre cose è gratuito ed open source, il che è utile anche per chi volesse approfondire la tematica. Encog ha una bella interfaccia grafica per comporre la rete neurale di interesse, per allenarla e verificarne il funzionamento su dati nuovi senza dover scrivere codice, quindi si adatta bene ai casi in cui è necessaria un po’ di sperimentazione.

Quanti neuroni allenare?

A questo punto il problema principale è la scelta del numero di neuroni che compongono la rete neurale. Come detto la terminologia è un po’ esotica ma non è casuale: nella sua formulazione matematica, infatti, la rete è definita proprio come un’interconnessione di unità minime dette neuroni, e il loro numero determina l’”intelligenza” della rete stessa!

Più precisamente, variare il numero di neuroni in una rete significa controllarne la complessità: tanti più sono i neuroni tanto più complessa potrà essere la funzione che collettivamente vanno ad emulare. Il problema è che una rete con molti neuroni, oltre ad essere molto potente, ha anche due svantaggi:

1. richiede moltissima potenza computazionale per essere allenata, quindi questa fase potrebbe richiedere ore o giorni, inoltre
2. rischia di imparare “troppo bene” dagli esempi forniti, nel senso che dopo l’apprendimento riconosce perfettamente quelli, ma poi sbaglia completamente con qualunque dato nuovo anche solo leggermente diverso. Questa “impossibilità di generalizzare” è detta in gergo overfitting ed è naturalmente da evitare.

Non sapendo cosa far di meglio ho seguito un approccio sperimentale variando più volte il numero di neuroni e vedendo quali risultati riuscivo a raggiungere.

Nota tecnica: l’effettiva efficacia di una rete va valutata su un insieme di lettere diverso da quello usato per l’allenamento, altrimenti si corrono grossi rischi di overfitting. Questa tecnica è generale e viene detta cross-validation, ed è supportata da Encog.

E’ obbligatorio che ogni rete a percettrone a strato nascosto singolo abbia:

• un neurone per ogni variabile in input (nel nostro caso, 225),
• un neurone per ogni variabile in output (nel nostro caso, 34),
• uno o più neuroni ulteriori detti “nello strato nascosto”.

Ovviamente, il punto cruciale è scegliere bene il numero di neuroni in quest’ultimo punto! Al termine delle mie prove il numero ottimo sembrava essere 75, uno per ogni 3 pixel in ingresso, portando quindi il totale a 334 neuroni (una rete di complessità medio-moderata). Stabilito questo si può “disegnare” la rete in Encog: qui sotto riporto una schermata del programma che mostra la struttura della rete ed il numero di neuroni.

Fatto questo si procede all’allenamento, che è un processo generalmente abbastanza lungo in cui la rete impara dagli esempi fino a ridurre la percentuale di errori sotto a un certo limite stabilito. Nella figura seguente, tratta ancora da Encog, si vede l’andamento dell’errore durante l’apprendimento.

Come si può notare la linea rossa che rappresenta il tasso di errore cala progressivamente fino a un minimo al quale l’allenamento si arresta, e la rete è pronta all’uso!

Note tecniche: per i dettagli di funzionamento di Encog rimando al sito ufficiale, poichè una spiegazione particolareggiata richiederebbe uno spazio eccessivo. Chiarisco soltanto alcuni punti:

• Encog ha bisogno di file CSV piuttosto che di immagini per l’allenamento, la conversione non è descritta perchè tutto sommato banale per chiunque sappia programmare;
• l’allenamento, in pratica, consiste nella taratura dei parametri della rete neurale in modo che approssimi la funzione voluta;
• esistono più algoritmi per l’allenamento, molti dei quali sono ancora in stato di attiva ricerca. L’algoritmo di default di Encog, detto resilient backpropagation, è molto buono e più che sufficiente per i nostri scopi;
• dall’interfaccia grafica dell’Encog Workbench si può esportare codice Java o C# che implementa la rete allenata, a questo punto il codice va integrato con tutte le procedure di trattamento delle immagini viste finora.

Prossimi passi

Se siete arrivati fin qui, complimenti, la parte dura è passata! Nel prossimo articolo tirerò le somme di quanto visto, farò un minimo di analisi statistica dei risultati e pubblicherò qualche spezzone di codice.

Scommetto che stavolta non era tutto così semplice e chiaro, fatevi sentire nei commenti che rispiego quel che manca oppure è confuso!

A breve pubblicherò la parte 5, se volete restare aggiornati abbonatevi al feed RSS! (a proposito, cos’è un feed RSS?)

Filtraggio e rimozione delle imperfezioni

Sistemato il rumore, il compito successivo è quello di separare i caratteri uno dall’altro. In effetti è abbastanza ovvio: riconoscere una lettera è essenzialmente indipendente dalla sua posizione in un dato testo.

Questo passaggio, che all’uomo risulta naturale, è un po’ più ostico per le macchine: bisogna pensare a un modo per distinguere i contorni delle lettere, che però non sempre sono ben definiti.

Per semplificare il problema, si applica generalmente un filtro threshold, ossia “di soglia”. Il suo funzionamento è molto semplice: ogni pixel dell’immagine viene “riscritto” in colore bianco se aveva un colore chiaro, al di sotto di una certa soglia, oppure in nero in caso contrario. Credo che un esempio sia molto più facile da capire:

Come si vede, i contorni sono più netti dopo il filtraggio, e adesso l’immagine è praticamente pronta per essere segmentata. Anche se si potrebbe procedere direttamente, ho preferito fare ancora qualche ulteriore operazione di miglioramento per eliminare alcune imperfezioni (più propriamente, artefatti) creati dal filtro precedente. Ne vediamo un esempio nell’immagine che segue:

Nella “B”, come si può notare, c’è un punto isolato nero, mentre nella “N” ce n’è uno bianco. In generale, siccome il filtro threshold viene applicato a immagini con una certa variabilità, può capitare che si creino delle piccole aree di colore isolate. Una soluzione per rimuovere questi difetti è contare, per ogni punto, quanti dei punti adiacenti sono bianchi: se sono la gran maggioranza, ad esempio più di 6 su 9, siamo di fronte a un pixel quasi isolato, e possiamo ricolorarlo in bianco. Discorso analogo si può fare, all’inverso, per i punti neri. Un’altra soluzione è quella di calcolare l’area di ogni parte dell’immagine con lo stesso colore, ed “eliminare” le aree molto piccole, ad esempio sotto i 10 pixel (certamente non rappresentano lettere). Io ho usato entrambi questi approcci, combinati, per rimuovere la maggior parte delle imperfezioni.

Segmentazione dei caratteri

A questo punto siamo pronti per la segmentazione vera e propria. Nel caso del CAPTCHA di Vodafone, a questo punto, i caratteri sono ben separati fra di loro e contigui nei loro tratti, quindi l’operazione è particolarmente semplice. In generale questo è il punto più difficile in assoluto!

L’algoritmo che ho scritto per separare le lettere usa il “flood fill” ed è usato nei programmi di grafica per riempire aree dello stesso colore. L’esempio più noto è lo strumento “secchiello” di Microsoft Paint, che permette di riempire di un certo colore porzioni uniformi dell’immagine.

Dettagli tecnici: l’algoritmo percorre l’immagine da sinistra a destra a varie altezze ed ogniqualvolta incontra un punto nero:

1. lo colora,
2. colora tutti i punti adiacenti fino a riempire l’area contigua (ossia la lettera) ed infine
3. cambia il colore (in modo che sia diverso per la prossima lettera).

Altri dettagli sugli algoritmi di flood fill, in particolare sul passo 2, sono reperibili sull’ottima pagina di Wikipedia.

Il risultato, anche se un po’ carnevalesco, rende perfettamente l’idea: le lettere sono separate.

A questo punto non resta che individuare, per ogni lettera, il più piccolo rettangolo che contenga tutti i punti dello stesso colore, quindi si possono estrarre le singole lettere.

Consiglio agli interessati dell’argomento una lettura dei manuali di Intelligenza Artificiale, in particolare consiglio caldissimamente il Russel-Norvig, una vera colonna portante della materia.

Prossimi passi

Scomposta l’immagine in lettere occorrerà normalizzarle per dimensione e, soprattutto, riconoscere i singoli caratteri, materia della prossima parte di questa serie di articoli. Si tratta della parte concettualmente più difficile, ma anche più interessante!

Tutto chiaro finora? Vai alla quarta parte!

Anatomia di un CAPTCHA: osservare per capire

Nell’immagine seguente trovate un insieme di esempi di sei CAPTCHA presi dal sito vodafone.it.

Tanto per iniziare, osserviamo che:

• il CAPTCHA è sempre formato da cinque caratteri, numeri o lettere. Per evitare ambiguità, alcuni caratteri come lo zero o la “O” non compaiono mai;
• le lettere sono distorte, in particolare sono “stirate” verticalmente o orizzontalmente;
• c’è del rumore di fondo dietro ogni immagine (apparentemente casuale).

Proprio l’ultimo punto rappresenta il punto di partenza ideale per il riconoscimento del CAPTCHA: se fosse possibile rimuovere il rumore, almeno in buona parte, si semplificherebbe parecchio il  riconoscimento. Come si può fare?

Come rimuovere il rumore di fondo

Esistono parecchie tecniche, dette senza troppa fantasia di riduzione del rumore, che potrebbero essere applicate in linea di principio in questo caso. In realtà non mi tufferò a spiegarle qui perchè esiste un modo particolarmente semplice di risolvere il problema senza neanche scomodarle!
Il sistema si basa su un piccolo difetto nella procedura di generazione di queste immagini, che i più attenti avranno probabilmente già notato. Guardando bene le immagini, infatti, ci si accorge che il rumore di fondo non è casuale, ma identico in ogni CAPTCHA!

Sovrapponendo le immagini si vede a colpo d’occhio:

A questo punto, ragionando per differenza su più di CAPTCHA, è possibile ricostruire una traccia quasi perfetta dello sfondo originario. Io ho usato un programmino ad hoc che confronta un centinaio di immagini, con il risultato che si vede sulla destra qui sotto, anche se con un po’ di pazienza si potrebbe fare anche manualmente.

Dettagli tecnici per gli appassionati: l’algoritmo, per ogni pixel, calcola la moda della sfumatura di grigio sull’insieme di immagini in esame. Il concetto è che il valore che si ripete più frequentemente sarà probabilmente quello dello sfondo; c’è poi una piccola correzione per escludere i valori troppo vicini al nero, che con ogni probabilità appartengono alle lettere.

Una volta nota l’immagine con il fondo del rumore, basta una “sottrazione per immagini” per ottenere un’immagine “pulita”, come nell’esempio seguente:

Altro dettaglio tecnico: la sottrazione non viene effettuata per i pixel molto vicini al nero nell’immagine da ripulire, in quanto con ogni probabilità appartengono alle lettere.

Prossimi passi

Arrivati a questo punto abbiamo un’immagine abbastanza buona. Il prossimo problema sarà quello di dividere i caratteri l’uno dall’altro (per leggerli individualmente, proprio come fanno le persone), e sarà affrontato nella terza parte di questa serie.

Tutto chiaro finora? Aspetto i vostri commenti!

Qualunque utente Internet di questi tempi si imbatte di tanto in tanto in un CAPTCHA, ossia in un controllo dell’”umanità” di chi sta alla tastiera, come il seguente:

Spesso mi viene chiesto: a cosa servono?
La ragione per cui moltissimi siti si dotano di CAPTCHA è la possibilità discriminare gli utenti veri da programmi automatici che potrebbero usare il sito in maniera non consona (ad esempio aprendo le sue pagine a ripetizione per danneggiarlo).

L’idea di questo fastidioso dispositivo è che si possa distinguere un umano da una macchina tramite un compito che sia:

• facile per un uomo ma
• difficile, o meglio impossibile per un computer

…proprio come leggere lettere distorte e senza senso! Si può infatti immaginare che un computer, non essendo intelligente, non sia in grado di leggere qualcosa di imperfetto. Ma è proprio vero?

Si possono aggirare i CAPTCHA?

Apparentemente, i CAPTCHA funzionano bene. In realtà, la distinzione tra ciò che una macchina può o non può fare rispetto all’uomo spesso non è così netta, ed è così anche per il riconoscimento ottico di oggetti come le lettere.
Esiste infatti un un intero ambito di ricerca, l’Intelligenza Artificiale, che si occupa proprio di “avvicinare” le capacità delle macchine a quelle dell’uomo. Tra gli altri interessanti ambiti dell’Intelligenza Artificiale c’è una disciplina detta OCR o Riconoscimento Ottico dei Caratteri che ha prodotto utili tecniche applicabili anche a questo problema.

Si può, allora, creare un programma basato sul’Intelligenza Artificiale per “leggere” un CAPTCHA, vanificando quindi il suo scopo?

Nella maggior parte dei casi, la risposta è un risonante SI’!
(ovviamente, a patto di dedicare un po’ d’impegno e di studio!)

Cercherò di sostenere questa tesi spiegando nel dettaglio come “battere” un CAPTCHA abbastanza semplice, quello usato dal sito di Vodafone Italia per gli SMS – con oltre il 90% di accuratezza al primo tentativo!

Chiaramente ogni CAPTCHA è un caso a sè, ma alcune idee fondamentali che illustrerò sono applicabili in generale. Nella prossima serie di articoli spiegherò l’anatomia di questo particolare CAPTCHA e di come sia riuscito a scrivere un programma che lo “legge”.

Vodafone Italia: siete in ascolto?

Aggiungo infine una nota doverosa: con questi articoli non voglio incitare il lettore ad aggirare le difese dei siti che conosce, il mio obiettivo è puramente di divulgazione dell’argomento e di sensibilizzazione sulle tematiche di sicurezza informatica. Saluto quindi calorosamente il personale Vodafone Italia, che ha tutta la mia simpatia (anche per l’ottimo trattamento che mi ha riservato durante il colloquio di lavoro): il vostro CAPTCHA era soltanto un esempio calzante, non ce l’ho con voi!

Prossimi passi

Nella seconda parte di questa serie di articoli mostrerò in dettaglio il CAPTCHA di vodafone.it ed introdurrò la tematica della riduzione del rumore, il primo passo essenziale per la lettura. Spiegherò successivamente tutti i passaggi fino ad all’interpretazione completa dell’immagine. Al termine della serie pubblicherò anche alcuni frammenti di codice Scala e Java che ho implementato e mettono in pratica le idee presentate.

Buona lettura!

sono molto spiaciuto, oggi, di dichiarare la fine ufficiale del programma e del forum. Mi spiace soprattutto per tutti quelli che mi hanno contattato in questi mesi e a cui ho risposto parlando del futuro – putroppo sono arrivato a un punto in cui neanche nella miglior futuro possibile riuscirei più a seguire tutti i progetti che ho aperto.

Sono soggetto a una crisi cronica di tempo libero – neanche le ferie del mese di Agosto sono state sufficienti a dare un po’ di respiro ai progetti, come MoioSMS, che da troppo tempo aspettano di essere aggiornati. L’errore è stato probabilmente di intraprenderne troppi: dovendo ora tirare le somme, a malincuore, sono costretto a tagliare da qualche parte.

Ho a lungo sperato di cavarmela con qualche trucco – la versione 3 avrebbe dovuto risparmiarmi diverse ore di sviluppo per la manutenzione, ad esempio – ma dalla piega che hanno preso le ultime settimane mi rendo conto che è inutile continuare a rimandare.

Spero che qualche sviluppatore ben intenzionato possa continuare a portare avanti quel che resta di MoioSMS, con un altro nome e un’altra squadra, ma magari con la stessa passione. Se ci siete, fatevi sentire nei commenti!

Un saluto,

PS: spero di riuscire a portare avanti almeno gli articoli qui su moioli.net. Tanto per cominciare oggi pubblico la prima parte di un articolo sui CAPTCHA e su come possano essere aggirati – spero sia di ispirazione per gli sviluppatori che leggono queste righe!

Lascio l’articolo qui per chi lo volesse leggere, ma le informazioni riportate sono essenzialmente obsolete.

Come anticipato a qualcuno sul forum, è mia intenzione rinnovare radicalmente MoioSMS. La prossima versione di MoioSMS, la numero 3, si baserà su una piattaforma del tutto diversa e, nelle speranze di chi scrive, occorrerà meno tempo per mantenerla aggiornata – una condizione essenziale perchè un progetto come questo, che è fatto nel tempo libero, possa sopravvivere. Cercherò anche, come sempre, di rendere il programma più semplice e funzionale per l’utente.

Questo articolo spiega le ragioni della mia decisione ed ha un taglio decisamente tecnico – spero che gli altri sviluppatori dicano la loro nei commenti.

Motivazioni del cambiamento

La ragione di una così drastica decisione è dovuta a più fattori, il principale è che ritengo Python una piattaforma non più soddisfacente per le esigenze di questo progetto. Nonostante sia perfetto per l’uso in Linux, ambiente dove il progetto è nato, non è così semplice mantenere una buona compatibilità anche con gli altri Sistemi Operativi (ad esempio, lo stato di manutenzione ed aggiornamento di py2exe e py2app lascia parecchio a desiderare).

Un punto dolente sono le librerie grafiche che anni fa scelsi per l’interfaccia utente, le famose WxWidgets, che nel tempo hanno mostrato una lunga serie di limiti, errori non risolti, carenze di documentazione e poca uniformità tra Windows, Mac e Linux.

Altro punto debole è il sistema di decodifica delle immagini CAPTCHA, più che macchinoso, inefficiente e dipendente da una serie di altri programmi. D’altra parte, Python non dispone a mio parere di un’implementazione sufficientemente buona delle reti neurali, gli oggetti matematici che si usano a questo scopo, quindi non è facile passare ad algoritmi migliori. Il fatto di usare programmi esterni, inoltre, ha dato origine a una serie di grattacapi su come rendere il programma autocontenuto, il che ha sollevato nuovi problemi con firewall ed antivirus in Windows.

I problemi di Python non si fermano qui: un’esigenza da troppo tempo trascurata è quella di ristrutturare l’applicazione in modo da funzionare su più thread di esecuzione, per evitare di bloccare l’interfaccia durante l’invio dei messaggi. Anche qui, il supporto di Python alla programmazione concorrente è rudimentale, soprattutto in ottica di indipendenza dalla piattaforma (questo è cambiato recentemente con librerie come Twisted, che però usa processi anzichè thread, una soluzione a mio parere sub-ottimale).

Nuove idee

Ho passato parecchio tempo prima di trovare, capire e scegliere la tecnologia giusta per superare questi problemi. La scelta è infine ricaduta sul linguaggio Scala, che fa uso della piattaforma Java. I vantaggi che mette a disposizione sono notevoli:

• permette di scrivere codice compatto, similmente a Python e a differenza di Java, pur restando un linguaggio tipato staticamente, il che aiuta lo sviluppatore a trovare difetti nel codice prima della sua pubblicazione;
• ha integrata una libreria per il multitheading basata sul modello ad attori, che ritengo essere decisamente buono (l’ho usato, tra le altre cose, nella mia tesi di secondo livello in quanto fornito direttamente in Qt come estensione del meccanismo signals&slots);
• essendo basato sulla piattaforma Java:
  • è meglio predisposto, rispetto a Python, per lo sviluppo su più piattaforme (vedi il concetto WORA: anche se non è vero in termini assoluti lo è in buona parte). Non ho dubbi, ad esempio, sul fatto che si possano realizzare interfacce più portabili in Swing piuttosto che WxWidgets per esperienze passate;
  • permette di accedere a un numero esorbitante di librerie, anche di alta qualità, già esistenti per Java, in particolare l’ottima libreria Encog per le reti neurali;
  • permette di ottenere eseguibili (Jar) più compatti rispetto agli exe/app attuali ed effettivamente eseguibili con un doppio click su tutte le piattaforme – al patto al più di installare un JRE su Windows qualora non sia già presente, cosa comunque facilmente aggirabile. Inoltre con poca fatica si possono ottenere Jar completamente autocontenuti, integrando la libreria per l’accesso http, la libreria per le reti neurali, i dati statici necessari e così via.

Cosa resta da fare

Le motivazioni che ho esposto non piovono dal cielo, in quanto prima di sbilanciarmi ho già preparato una versione (molto) preliminare di MoioSMS che riesce a mandare messaggi da Vodafone con un algoritmo apposito di decodifica dei CAPTCHA che arriva a un quasi-incredibile 92% di accuratezza. Nel prossimo periodo scriverò qui sul sito alcuni articoli che spiegheranno come il sistema funziona.

Nel frattempo punto a rilasciare una prima versione utilizzabile di MoioSMS 3. Per evitare di aspettare altri anni dapprincipio non ci saranno molti dei siti inizialmente supportati e molte funzionalità dovranno essere aggiunte in seguito, ma fin da subito dovrebbero vedersi i frutti della nuova architettura:

• un eseguibile autocontenuto, compatto e comune a tutte le piattaforme, con molti meno problemi di dipendenze;
• la spedizione degli SMS in un thread separato;
• decodifica dei CAPTCHA (inizialmente, di Vodafone) estremamente più veloce ma soprattutto
• un tempo di risposta ai problemi degli utenti inferiore.

Agli altri sviluppatori

Innanzitutto, grazie per tutto quello che avete fatto in questi mesi. Temo che qualcuno di voi non sarà contento di leggere queste righe – l’abbandono di Python sarà un divorzio doloroso, e forse non strettamente necessario, ma spero che condividiate le mie ragioni e che continuiate ad operare nella comunità di MoioSMS. E’ mia intenzione coinvolgervi maggiormente rispetto al passato, ovviamente se siete disponibili, iniziando da una discussione sulle idee in questo articolo.

A presto!

E’ più facile da vedere che da spiegare, quindi buona visione!

• Video di laurea su Vimeo per la visione diretta;
• Video di laurea in versione mp4 per il download (68 MB).

Da ieri questo sito ha cambiato provider da Aruba.it ad Unbit.it.

Come sempre in questi casi è prevedibile qualche sobbalzo o qualche piccolo malfunzionamento: per il momento l’esperienza è ottima ma se riscontrate errori o problemi del sito fatemi sapere all’indirizzo silvio at moioli punto net.