BigInteger p = BigInteger.probablePrime(keyLength/2, new SecureRandom()); // Generiamo un numero "probabilmente" primo, p
		BigInteger q = BigInteger.probablePrime(keyLength/2, new SecureRandom()); // Generiamo un numero "probabilmente" primo, q

		// Calcoliamo n e phi
		BigInteger n = p.multiply(q);
		BigInteger phi = p.subtract(new BigInteger("1")).multiply(q.subtract(new BigInteger("1")));

		// publicKey conterra' l'esponente pubblico e,
		// scegliendo e come il primo numero primo successivo a
		// p, esso sara' anche coprimo con phi (come richiesto nell'algoritmo)
		this.publicKey = p.nextProbablePrime();
		this.privateKey = publicKey.modInverse(phi);
		this.n = n;
	}

Una precisazione sulla funzione probablePrime() e nextProbablePrime(): esse restituiscono un numero che probabilmente e’ primo, utilizzando dei test di probabilita’ probabilistici. Il margine di errore e’ molto basso: per essere precisi, la probabilita’ che un numero restituito da queste due funzioni sia composto e’ sempre minore di 2^-100 e la velocita’ dell’algoritmo lo rende preferibile ad uno deterministico nella generazione delle chiavi. Una volta generate le chiavi, si possono gia’ creare le due funzioni di base per criptare/decriptare un numero intero. Ecco il codice:

	public BigInteger encrypt(BigInteger m) {
		return m.modPow(publicKey, n); // (m^publicKey) % n
	}
	public BigInteger decrypt(BigInteger m) {
		return m.modPow(privateKey, n); // (m^privateKey) % n
	}

Dovrebbe essere abbastanza chiaro. La funzione modPow(e, n) restituisce semplicemente this ^ e % n e ci risparmia un po di calcoli. Con queste due semplici funzioni possiamo pero’ criptare unicamente numeri interi; per poter usare l’algoritmo su un testo piu’ o meno lungo dobbiamo creare altre due funzioni che processano il testo in maniera tale da essere compatibile con l’algoritmo, i passi principali saranno questi:

1. aggiungere del padding (casuale) al testo in modo da renderlo divisibile in blocchi di uguali dimensioni. la dimensione di ogni blocco sara’ la lunghezza della chiave.
2. processare ogni blocco, convertire il testo in un intero e cifrarlo

Per il processo inverso, invece:

1. dividere il testo nel numero di blocchi in base alla chiave.
2. decriptare ogni blocco e convertire gli interi nel testo corrispondente
3. rimuovere il padding.

Ecco il codice con alcuni commenti esplicativi:

	public String encrypt(String m) {
		/* Per comodita' (piu' sotto si vedra' perche') convertiamo i
		 * caratteri del messaggio nel loro codice ASCII (esadecimale)
		 */
		String mHex = "";
		for (int i = 0; i < m.length(); i++) {
			mHex += Integer.toHexString(m.charAt(i));
		}

		/* Calcoliamo quanto padding e' necessario, chiamiamolo N, e poi concateniamo al messaggio
		 * N-1 bytes di padding casuale. L'ultimo non deve essere casuale ma deve contenere appunto
		 * il numero N, cosi' da poter poi rimuovere la giusta quantita di padding nella funzione decrypt().
		 */
		int padding = blockSize - (mHex.length()/2)%blockSize;
		for (int i = 0; i < padding-1; i++) { // Prima generiamo N-1 byte casuali
			int randomPadding = (int)(10*Math.random());
			mHex += randomPadding < 10 ? "0" + Integer.toHexString(randomPadding) : Integer.toHexString(randomPadding);
		}
		// Ultimo byte di padding
		mHex += padding < 10 ? "0" + Integer.toHexString(padding) : Integer.toHexString(padding);

		int numBlocks = (mHex.length()/2)/blockSize; // Numero di blocchi in cui dividere il messaggio

		String result = "", currentBlock = "";
		for (int b = 0; b < numBlocks; b++) {
			currentBlock = mHex.substring(b*blockSize*2, (b+1)*blockSize*2);

			/* Il blocco corrente, essendo una stringa in formato esadecimale,
			 * quindi un numero, puo' essere criptato con le due funzioni che abbiamo gia'
			 * creato precedentemente che accettano come argomento un BigInteger.
			 */
			// Questo costruttore accetta una stringa, e la base come secondo argomento
			BigInteger r = encrypt(new BigInteger(currentBlock, 16)); 

			/* Puo' accadere che la string che otteniamo come risultato abbia un byte in meno,
			 * in questo caso, per non avere problemi nel decriptare il messaggio, aggiungiamo
			 * uno zero iniziale che non cambia niente, ma la rende della dimensione corretta.
			 */
			if (r.toString(16).length() == blockSize*4) {
				result += r.toString(16);
			} else {
				result += ("0" + r.toString(16));
			}
		}
		return result;
	}

	public String decrypt(String m) {
		int numBlocks = (m.length()/2)/(blockSize*2);

		String temp = "", currentBlock = "";
		/* Questo ciclo, quasi uguale a quello della funzione encrypt(), scorre ogni
		 * blocco, lo decripta e concatena il risultato in una nuova stringa.
		 */
		for (int b = 0; b < numBlocks; b++) {
			currentBlock = m.substring(b*blockSize*4, (b+1)*blockSize*4);
			BigInteger r = decrypt(new BigInteger(currentBlock, 16));
			temp += r.toString(16);
		}

		/* Il padding e' uguale all'ultimo byte della
		 * stringa, come avevamo precedentemente impostato.
		 */
		int padding = Integer.parseInt(temp.substring(temp.length()-2), 16);
		int actualLength = temp.length() - padding*2;

		// Rimuove il padding
		temp = temp.substring(0, actualLength);

		String result = "";
		// Riconverte la stringa da esadecimale a testo
		for (int i = 0; i < temp.length(); i+=2) {
			result += (char)Integer.parseInt(temp.substring(i,i+2), 16);
		}
		return result;
	}

Tutto il codice e’ contenuto in questo archivio disponibile per il download.

L’idea di base della crittografia a chiave pubblica serve proprio a porre fine a questo inconveniente e a rendere non piu’ necessaria una comunicazione preliminare (e sicura) tra le parti per scambiarsi una chiave. In un algoritmo a chiave asimmetrica vengono infatti create due chiavi anziche’ una: quella pubblica verra’ usata da chi vuole cifrare un messaggio da inviare al possessore di quella chiave, quella privata verra’ utilizzata dallo stesso per decifrare il messaggio ricevuto. La chiave pubblica di ognuno viene, insomma, resa disponibile a chiunque voglia inviargli un messaggio, che sara’ poi decifrabile solamente usando la chiave privata, tenuta segreta.

Chiaramente le due chiavi devono essere correlate in qualche modo per avere la proprieta’ sopra descritta, e cioe’ che si possa crittografare un testo con una chiave (quella pubblica) e decriptarlo con un’altra (quella privata) ottenendo lo stesso testo di partenza. In particolare, esistendo questa relazione tra le chiavi bisogna evitare che dalla chiave pubblica, che tutti possono leggere, si possa risalire a quella privata. Bisogna cioe’ trovare un modo per generarla che sia facile da percorrere in un verso (cioe’ generare la chiave), ma che sia quasi impossibile da percorrere nell’altro, cioe’ trovare i dati usati per generarla partendo dalla chiave pubblica (altrimenti, una volta ottenuti i dati, si potrebbe generare la chiave privata ad essa associata).

I primi ad inventare un tale sistema furono W. Diffie e M. Hellman nel 1976, ma fu nel ‘77 che Rivest, Shamir e Adleman, tutti studenti del MIT, realizzarono uno degli algoritmi a chiave pubblica piu’ utilizzato al giorno d’oggi e che prende il nome di RSA. La sicurezza dell’algoritmo RSA si basa sulla difficolta’ di fattorizzare in tempi accettabili il prodotto di due grandi numeri primi: infatti, mentre e’ facilissimo calcolare il prodotto di questi due numeri, non esiste un algoritmo che possa fattorizzarlo velocemente. Nel resto di questo articolo vedremo a grandi linee come opera l’algoritmo RSA mentre nella seconda parte vedremo un’implementazione in Java.

In linea generale possiamo distinguere tre “fasi” dell’algoritmo: generazione delle chiavi, criptaggio, decriptaggio (si, lo so che suonano malissimo).

Generazione delle chiavi

1. Si generano due grandi numeri primi p, q tali che il loro prodotto n = pq ha la lunghezza in bit che desideriamo.
2. Si calcola n = pq, e phi = (p-1)(q-1)
3. Si sceglie un intero positvo e < phi e coprimo con phi (cioe’ MCD(e, phi) = 1)
4. Si calcola un intero positivo d < phi tale che ed ≡ 1 (mod phi)
5. La coppia (n, e) forma la chiave pubblica, la coppia (n, d) quella privata.

Criptaggio
Per criptare un messaggio si ottiene la chiave pubblica del destinatario e, dopo aver trasformato il messaggio di testo in un numero intero, si utilizza la formula c = m^e mod n, dove m e’ il messaggio.

Decriptaggio
Partendo dal testo criptato si usa la formula m = c^d mod n, dove c e’ il testo cifrato.

L’unico modo per decriptare un messaggio, come e’ evidente dall’algoritmo, e’ quello di essere a conoscenza dell’esponente segreto d e del modulo, n. Mentre l’esponente e’ segreto, il modulo e’ pubblico poiche’ e’ utilizzato anche per criptare il messaggio: ad ogni modo, per risalire a d, che permetterebbe di accedere al contenuto del messaggio, abbiamo bisogno non di n, ma di p e q, i due grandi numeri primi usati per generarlo. Se i numeri primi sono abbastanza grandi, e’ impossibile fattorizzare n in tempi accettabili con gli algoritmi attuali.

In questo articolo non abbiamo visto una prova teorica del funzionamento dell’RSA e cioe’ una prova del fatto che criptando un messaggio con la chiave pubblica e decriptandolo con la chiave privata si ottiene sempre di nuovo il messaggio in chiaro, ma potete trovare una dimostrazione (in inglese) a questo link: http://www.di-mgt.com.au/rsa_theory.pdf. Per comprenderla sono necessarie nozioni (non troppo avanzate) di teoria dei numeri.

Per Phil Carmody l’idea che del codice sorgente potesse essere intrinsecamente illegale era assolutamente bizarra, e cosi’ si mise a cercare un modo di rappresentare il codice di DeCSS che non potesse essere in alcun modo considerato illegale. Il sito che attualmente si trova a questo indirizzo archiviava, e archivia ancora, i numeri primi che hanno particolari proprieta’. Cosi’, armatosi di molta pazienza e di vari tool per lavorare sui numeri primi (come test di primalita’ probabilistici o deterministici), riusci’ a trovare un numero primo abbastanza lungo (1901 cifre) da meritare di essere archiviato sul sito, anche perche’ rientrava nella top 20 dei numeri primi testati con l’algoritmo ECPP. Tra l’altro, visto che gzip ignora i caratteri dopo uno zero binario alla fine di un file compresso, dovrebbero in realta’ esistere infiniti numeri primi che rappresentano la stessa cosa, cioe’ il codice compresso di DeCSS.

Dopo qualche mese, Phil Carmody e’ anche riuscito a trovare un numero primo che rappresenta un eseguibile valido in ambiente Linux e che offre le stesse funzionalita di DeCSS. Se volete qualche dettaglio piu’ tecnico sulla ricerca di questi due numeri primi potete visitare questa e questa pagina. Se non vi fidate sul fatto che quel numero primo corrisponda esattamente ad un archivio che genera il codice di DeCSS vi lascio questo programma in Perl (non scritto da me, ma opera di un certo Jamie McCarthy) che prende il numero primo da una pagina web, crea un archivio gzip ed estrae il codice:

#!/usr/bin/perl
use LWP::Simple;
use Math::BigInt;
my $html = get("http://www.utm.edu/research/primes/curios/48565...29443.html");
my($prime) = $html =~ m{<blockquote>([^<]+)</blockquote>};
$prime =~ s{\D+}{};
$prime = Math::BigInt->;new($prime);
my $binary = '';
while ($prime > 0) {
$binary = pack("N", ($prime % 2**32)) . $binary;
$prime /= 2**32;
}
$binary =~ s{^\0+}{};
open(my $fh, "| gunzip -c 2>/dev/null") or die "cannot gunzip, $!";
print $fh $binary;
close $fh;

Sulla pagina inglese di Wikipedia dedicata ai numeri primi illegali trovate anche i due numeri (quello del file gzip e quello del file eseguibile) che ho omesso in questo articolo. Alla prossima.

PS: fateci anche sapere se vi piace il nuovo tema.

Molecola animata TNF

Materiali • 50 aspirine (qualsiasi marca va bene) • Alcol metilico o etilico senza coloranti • 150 ml Acido solforico ad alta concentrazione • 60g di nitrato di sodio o 80g di nitrato di potassio • Acqua distillata e ghiaccio • Vaselina • Cera (paraffina)

Estrazione dell’acido acetilsalicilico

Le aspirine, così come vengono vendute, contengono degli eccipienti che potrebbero ostacolare le varie reazioni. E’ quindi necessario un processo per isolare il solo acido acetilsalicilico. Prendete le aspirine e frantumatele fino ad ottenere una polvere. Versate in una ciotola dell’alcol metilico caldo (circa 40 °), e metteteci dentro la polvere di aspirina. Agitate con un cucchiaio per almeno 2 minuti. Non tutta la polvere si dissolverà, ma ne rimarrà una parte sul fondo. Dovete filtrare il tutto, conservando solamente il liquido senza la parte insoluta. Mettete la soluzione ad evaporare. Otterrete dei cristalli bianchi sul fondo, quello è acido acetilsalicilico puro.

Procedimento

Prendete 40g di acido acetilsalicilico e dissolvetelo il 150ml di acido solforico. Riscaldate la soluzione per favorire la dissoluzione dei cristalli. In questo modo otterrete dell’acido fenolsulfonico, che dopo la nitrazione diventerà acido picrico. Il prossimo passaggio ha bisogno di un’ottima ventilazione, e possibilmente anche di una mascherina per proteggersi dai fumi tossici. Quindi LENTAMENTE aggiungete 60g di nitrato di sodio, o in alternativa 80g di nitrato di potassio, mescolando mentre versate. Durante questo passaggio si formerà del fumo rosso, questo è triossido di azoto, il quale è molto tossico anche a basse quantità. Non inalatelo per nessun motivo. Mentre aggiungete il nitrato, state anche attenti alla schiuma che si formerà perché potrebbe far traboccare l’acido fuori dal recipiente. A questo punto la soluzione deve essere raffreddata, versandola lentamente in un recipiente contenete acqua distillata e ghiaccio macinato. Vedrete formarsi dei cristalli di un color giallo accesso. Filtrate questi ultimi, e immergeteli in dell’acqua distillata bollente, lasciate poi raffreddare il tutto a temperatura ambiente. Avrete ottenuto del trinitrofenolo (acido picrico) molto puro.

Plastificare l’esplosivo

Potete mischiare i cristalli ottenuti con il 10% di cera e 5% di vaselina. Fatele fondere e poco prima che il tutto si solidifichi, versate i cristalli di trinitrofenolo mescolando. Avrete ottenuto un buon esplosivo al plastico, utilizzabile tra i 0 ° e i 40 ° C.

Precauzioni

Il trinitrofenolo è molto tossico. Non va assolutamente messo a contatto con i metalli perché forma dei sali altamente instabili. Usare i guanti per maneggiarlo.

In questo articolo un tipo di estrazione molto comune in ambito chimico, ed è usata principalmente per estrarre i principi attivi dai vegetali, e precisamente degli alcaloidi. Questi ultimi prendono Il nome da alcalis, ovvero basico. Sono componenti dal gusto amaro e anche più o meno tossici (un esempio banale è la caffeina). Nella loro struttura molecolare è sempre presente almeno un atomo di azoto legato a dei metaboliti organici. Per ogni alcaloide i componenti utilizzati per l’estrazione sono leggermente diversi, ma il metodo che andrò a descrivere è generalizzato e quindi applicabile a tutti gli alcaloidi.

Di seguito riporto gli alcaloidi più comuni che è possibile estrarre con questo metodo.

• Caffeina

• Nicotina

• Cocaina

• Morfina

• LSA

• DMT

e molti altri.

MATERIALE NECESSARIO

• Almeno 5 vasi di vetro, le dimensioni dipendono dalla quantità di materiale organico.

• Acido muriatico (in alternativa potete usare del semplice succo di limone o aceto di

vino bianco)

• Soda caustica o bicarbonato di sodio

• Acqua distillata

• Solvente organico non polare (vedi in seguito)

• Cartine tornasole

• Una calza, un filtro da caffè a trama fine o analogo

• Un piatto di ceramica

• Una discreta quantità di materiale organico secco

.

SOLVENTE ORGANICO NON-POLARE

Il solvente è quello che permette di estrarre gli alcaloidi in forma base dalla soluzione basica. Deve essere non-polare, ossia non deve mescolarsi con l’acqua ma creare due livelli ben distinti (è quello che succede con l’aceto e l’olio per farla semplice). Ecco alcuni solventi organici non polari adatti al nostro scopo:

• Naphta (ossia il petrolio bianco. Vi sconsiglio il suo utilizzo, anche se il suo costo è molto basso, ma i suoi tempi di evaporazione sono molto lunghi)

• Etere di petrolio (costa più della naphta ma evapora in pochissimo tempo e lascia pochi residui. Viene usato per l’estrazione industriale della cocaina)

• Cloruro di Metile (questo è estremamente tossico, se lo usate munitevi di mascherine. Inoltre creerà un livello che sta al di sotto della soluzione acquosa, al contrario dell’etere e della naphta)

Questi solventi sono molto volatili e infiammabili, è opportuno prendere le dovute precauzioni.

.

FASE 1: Preparazione del materiale e sua decantazione in soluzione acida

Prendete la vostra scorta di materiale organico e polverizzatela il più possibile, aiutandovi anche con un frullatore. Per facilitare questa operazione potrebbe essere utile congelare il materiale e poi triturarlo. Prendete un vaso di vetro sufficientemente grande per contenere tutto il vostro materiale, riempitelo per metà di acqua distillata e aggiungeteci un po di acido muriatico. Se usate il limone, spremete un limone intero per ogni 500ml d’acqua. Per essere precisi, usate le cartine tornasole e verificate che il pH sia circa 3. Non esagerate con l’acidificazione. Ora versate il materiale all’interno della soluzione acida (Il liquido deve essere quasi il doppio del volume vegetale, fate sembrare il tutto ad un minestrone). Lo scopo di questa fase è fare in modo che la maggior parte degli alcaloidi si trasformi in sali, e quindi solubili in acqua. Per velocizzare il processo riscaldate il tutto senza far evaporare il liquido, e mescolate ogni tanto. Lasciate riposare per almeno 48 ore, sempre mescolando di tanto in tanto.

.

FASE 2: Filtrare il contenuto del primo vaso ed eliminare i componenti indesiderati

Preparate un altro vaso, di dimensioni simili al precedente e stirate bene sulla sua imboccatura un pezzo di calza. Vi servirà come filtro. Versate il contenuto del primo vaso nel secondo, facendo passare il liquido attraverso la calza. Tutto il materiale vegetale potrà essere scartato una volta filtrata completamente tutta la soluzione acida. A questo punto vi ritrovate con una soluzione acida, privata da componenti indesiderati, al cui interno sono presenti gli alcaloidi sotto forma di sali. Versate in questa soluzione il vostro solvente organico. Non serve esagerare, per 500ml di soluzione bastano 75ml di solvente. Agitate il tutto, e lasciate che si formino due livelli. Se usate il cloruro di metile, il livello del solvente andrà a formarsi sul fondo. Vedrete che verranno “catturate” delle sostanze, visibili sotto forma di una poltiglia all’interno del solvente. Quando i due livelli saranno ben distinti dovete eliminare quello del solvente, per farlo vi conviene utilizzare un recipiente con un piccolo rubinetto sul fondo.

.

FASE 3: Basificare la soluzione

Ora sarò necessario basificare la soluzione acida ottenuta precedentemente. Per fare questo versate in un recipiente dell’acqua distillata, e successivamente aggiungeteci della soda caustica. Il pH deve risultare circa 10. Versate un po’ di questa soluzione nella soluzione acida filtrata nella fase precedente. Il liquido diventerà più scuro, e avverrà una reazione esotermica, i cui scatenanti sono l’acido e la base che entrano in contrasto. Gli alcaloidi che precedentemente erano dei sali, ora ritorneranno nella loro forma base e saranno completamente separati dall’acqua.

.

FASE 4: Estrazione degli alcaloidi dalla soluzione

Per estrarre gli alcaloidi dalla soluzione dovete solo versarci dentro del solvente organico, agitare, e aspettare che si formino due livelli ben distinti. Usate etere, cloruro di metile o petrolio bianco. Dovete agitare il tutto in modo da creare un emulsione. Aggiunto il solvente e agitato, dovete lasciare riposare per almeno 24 ore (chiudete con un tappo il recipiente, altrimenti il solvente potrebbe evaporare soprattutto se è etere). Alla fine ritroverete due livelli ben distinti. Ricordate che se usate il cloruro di metile, il suo livello resterà sul fondo. Il solvente “catturerà” i vostri alcaloidi. Ora dovete isolare il solvente dal resto della soluzione acquosa. Vi conviene utilizzare sempre un recipiente con un piccolo rubinetto sul fondo.

.

FASE 5: Evaporazione del solvente

Arrivati a questo punto non vi resta che far evaporare il solvente e quindi ottenere gli alcaloidi sotto forma di cristalli. Versate il solvente in un piatto di ceramica e lasciate che evapori completamente. A completa evaporazione il residuo rimasto saranno i vostri alcaloidi, solitamente sotto forma di cristalli.
Per velocizzare il processo potete riscaldare il piatto, ma mai oltre i 40° C perché i solventi sono molto infiammabili. Il tempo di evaporazione è comunque diverso da solvente a solvente. Diciamo che utilizzando l’etere, in massimo 48 ore non avrete più sue tracce, la naphta, invece, può necessitare anche più di una settimana per evaporare completamente

.

Conclusioni

Come avevo già detto, con questo metodo potete estrarre facilmente in casa i principi attivi contenuti nelle piante, sempre se questi ultimi siano degli alcaloidi. Se il metodo viene applicato in modo preciso, si può anche ottenere un risultato discretamente puro. Con grandi quantità di materiale vegetale riuscirete ad ottenere una buona quantità di principi attivi più o meno puri.

Quello che vedete ora nell’editor e’ il codice di base per un robot molto semplice che non fa altro che muoversi avanti e indietro e girare il suo cannone di 360 gradi, sparando quando vede un nemico. Ma analizziamo piu’ da vicino il codice:

public class MURobot extends Robot {

Creiamo una classe che eredita tutti gli attributi e i metodi dalla classe di base Robot.

	/* Qui possiamo dichiarare tutte le variabili utilizzate dal nostro robot,
	 * in questo caso non ne abbiamo.
	 */
	public void run() {
		while(true) {
			ahead(100);
			turnGunRight(360);
			back(100);
			turnGunRight(360);
		}
	}

Dopo aver dichiarato le eventuali variabili utilizzate all’interno della classe, vediamo il metodo run(). Questo metodo viene chiamato ogni qualvolta inizia la battaglia. All’interno di run() si trova quasi sempre un ciclo infinito: se l’esecuzione di run() termina, infatti, il nostro robot non fara’ altro che stare fermo e sparare ai robot che rientrano nel suo campo visivo. Se dobbiamo svolgere delle azioni particolari, come il posizionamento in una particolare zona della mappa, conviene inserirle prima di entrare nel ciclo infinito.
All’interno del ciclo il robot si muove in avanti (ahead(100)) fa un giro completo del cannone, torna indietro, fa lo stesso giro e cosi’ finche’ non viene distrutto o distrugge tutti i robot nell’arena.

	public void onScannedRobot(ScannedRobotEvent e) {
		fire(1);
	}

Il metodo onScannedRobot() e’ uno dei tanti metodi per gestire gli eventi forniti di default. Questo metodo viene automaticamente eseguito quando un robot nemico rientra nel campo visivo del nostro: in questo caso l’azione e’ di sparare. L’oggetto e (sta per event) passato come argomento contiene informazioni utili come la direzione del proiettile, la distanza da noi, etc… non utilizzate nel nostro caso. Potete consultare la documentazione sulle API di Robocode che e’ molto esaustiva a riguardo.

	public void onHitByBullet(HitByBulletEvent e) {
		turnLeft(90 - e.getBearing());
	}
}

L’ultimo metodo viene chiamato quando il nostro robot viene colpito da un proiettile: per evitare di essere colpiti di nuovo il robot si gira nella direzione perpendicolare al proiettile e quindi si sposta grazie alle istruzioni all’interno del metodo run(). Il metodo getBearing() restituisce l’angolo tra la direzione in cui ci stiamo muovendo e la direzione del proiettile ed e’ sempre compreso tra -180 e 180, ed e’ uno dei tanti metodi di cui vi parlavo in precedenza.

Se provate a iniziare una battaglia tra questo robot e altri leggermente piu’ avanzati presenti gia’ di default, vi accorgerete che le sue prestazioni non sono proprio ottimali, di fatto perdera’ la maggior parte delle battaglie se non tutte (ovviamente dipende contro chi lo fate combattere), ma e’ comunque un inizio. Il metodo migliore per realizzare robot sempre piu’ avanzati e’ cominciare da subito a crearne: ricordate anche che avendo abbastanza padronanza con Java non ci sono limiti a quello che si puo’ realizzare!

La risposta è no, e le motivazioni saranno date nel corso dell’articolo.
Convincere un audiofilo condizionato dalla pubblicità martellante, che i cavi non migliorano le caratteristiche del suo impianto non è cosa facile, ma alla fine di questo articolo vedrete che tutti quelli che comprano dei cavi “speciali” vi sembreranno solo degli idioti, od al massimo dei fanatici dell’estetica.
Andiamo con ordine. Ci sono due tipi di cavi per impianti Hi-Fi: quelli per collegare le fonti audio al preamplificatore e quelli per collegare l’amplificatore agli altoparlanti.

I cavi per altoparlanti

Questi cavi vengono usati per collegare l’amplificatore agli altoparlanti e solitamente sono delle semplici piattine a due fili. La prima peculiarità che i produttori di cavi “speciali” promettono è un’induttanza molto bassa. Ma vediamo perché questa caratteristica è ininfluente in un comune impianto casalingo.
L’induttanza del cavo potrebbe influire sul segnale soltanto se questo raggiungesse una lunghezza pari a ¼ d’onda. La formula per calcolare la lunghezza d’onda in metri conoscendo la frequenza in Khz è:

lunghezza d’onda = 300.000 : Khz

Da ciò si capisce che l’induttanza del cavo influisce notevolmente sul segnale solo se ha una lunghezza maggiore di:

300.000 : 25 = 12.000 metri

12.000 :4 = 3.000 metri

Quindi se all’uscita dell’amplificatore e all’ingresso della cassa acustica applicassimo un cavo lungo 3 chilometri, allora questo potrebbe avere la sua influenza, ma poiché solitamente la lunghezza di questi cavi – in ambito casalingo, ma anche in altri luoghi – non supera mai una decina di metri e la gamma delle frequenza acustiche va da un minimo di 10 Hz ad un massimo di 20.000 Hz, il segnale di bassa frequenza arriva alle casse senza alcuna alterazione.
L’induttanza di un cavo che abbia i fili appaiati varia al variare del diametro del filo da un minimo di 0,3 microHenry per metro ad un massimo di 0,8 microHenry per metro. L’induttanza è maggiore se il filo è sottile, minore se il filo è grosso. Solo le frequenze tra i 15.000 – 20.000 Hz possono venire attenuate da un’induttanza eccessivamente elevata.

Altra cosa che i cavi “speciali” promettono di ridurre è la capacità parassita: anche questa varia al variare del diametro del filo; più questo è grosso più la capacità è alta, al contrario più è sottile e più la capacità sarà bassa. Alcuni consigliano di distanziare i due fili della piattina per ridurre la capacità parassita. Questo è vero, ma è altrettanto vero che l’induttanza aumenterà eccessivamente. In ogni caso la capacità parassita – se non troppo elevata – non influenza assolutamente il suono. Quanto detto vale per cavi non più lunghi di 10-12 metri, e quindi nella maggior parte degli impianti casalinghi.

Alcuni possessori di questi cavetti potrebbero obiettare dicendo che il suono è realmente migliore, e che quindi hanno speso bene i loro soldi. E’ chiaro che costoro sono stati semplicemente suggestionati dalla pubblicità e dall’apparenza vistosa di certi cavi che presentano contatti dorati, plastiche colorate etc. Per stabilire le differenze tra un cavo e l’altro, qualora ve ne fossero, non è sufficiente l’orecchio umano ma apparecchiature professionali come oscilloscopi, analizzatori di spettro, distorsimetri, audiotracer etc., perché solo con questi strumenti è possibile misurare anche quelle piccole differenze che l’orecchio umano non potrà mai per sua natura rilevare.

In definitiva abbiamo visto come l’unica cosa che potrebbe mutare in qualche modo il suono è l’induttanza del cavo, ma vi posso assicurare che non serve spendere cifre esorbitanti per dei cavi con bassa induttanza. E’ sufficiente acquistare un comunissimo cavo di gomma con 4 cavetti conduttori al suo interno. Il diametro deve essere proporzionato alla potenza del vostro amplificatore. L’unica cosa che dovete fare è collegare in parallelo due fili, ottenendo così un perfetto cavo per altoparlanti con un’induttanza parassita che potrà variare da un minimo di 0,25 microHenry per metro ad un massimo di 0,4 microHenry per metro. Avrete ottenuto, con una spesa irrisoria, un cavo tranquillamente paragonabile a quelli più costosi e rinomati.

Cavo artigianale per altoparlanti

.

I cavi d’ingresso per i preamplificatori

Questi cavi differiscono dai precedenti perché sono schermati. Questi tipi di cavi si possono trovare con sostanziali differenze di prezzo. Del comune cavo schermato si può trovare a circa 0,30 centesimi al metro, ma quelli tanto pubblicizzati dalle riviste hanno dei costi imbarazzanti. Quando si va ad applicare un segnale di BF su questi cavetti, non importa se la frequenza è di 100 Hz o di 20,000 Hz, poiché sull’estremità opposta preleveremo sempre queste due identiche frequenze. L’unica differenza che si riscontra tra i cavi schermati comuni e quelli “firmati” è la loro capacità parassita, esattamente come avevamo visto per gli altri cavi. Si può sminuire anche qui questa peculiarità dicendo che la capacità potrebbe influire sull’ampiezza delle sole frequenze dei super-acuti, e comunque soltanto nei casi in cui venissero usati dei cavetti più lunghi di 3 metri – cosa improbabile visto che solitamente la sorgente e l’amplificatore sono molto vicini.

Quanto detto si può provare con una formula per calcolare il taglio di frequenza di un filtro passa/basso, ovvero qualsiasi cavo schermato:

Herz = 159.000 : (R1 kiloohm x C1 nanoF)

R1 è il valore dell’impedenza d’uscita della sorgente, quindi se prendiamo il massimo valore che è 2000 ohm otteniamo 2 kohm. C1 è la capacità parassita del cavo espressa in nanofard. un normalissimo cavo schermato ha solitamente una capacità parassita di 400 picofard, quindi otteniamo 0,4 nanofard.

159.000 : (2 x 0,4) = 198.750 Hz

Questo significa che tutte le frequenze inferiori a 198.750 hz non subiranno nessuna attenuazione. Poiché la massima frequenza che il nostro orecchio riesce a percepire si aggira attorno ai 20.000-22.000 hz, è chiaro che un cavo del genere si può tranquillamente usare anche in ambito Hi-Fi. I più pignoli possono usare un cavo coassiale di tipo RG.174, il quale costa poco più dei cavi schermati normali ma ha una capacità parassita non superiore a 100 pF.

.

Conclusione

In ultimo spendere cifre esorbitanti in cavetti sperando di migliorare le prestazioni del proprio impianto Hi-Fi è pura follia. Comprare certi cavi è farsi fregare allegramente dai produttori degli stessi. Al lato pratico non c’è nessunissima differenza, l’unica cosa che cambia è l’estetica, ma volete realmente spendere dei soldi per abbellire qualcosa che solo la polvere potrà vedere?

]]> http://mindunpacked.com/2009/i-cavi-per-gli-impianti-hi-fi/feed/ 11 http://mindunpacked.com/2009/matrici-e-filtri-di-convoluzione/ http://mindunpacked.com/2009/matrici-e-filtri-di-convoluzione/#comments Sat, 10 Jan 2009 17:23:34 +0000 Francesco http://mindunpacked.com/?p=310 Per matrice di convoluzione si intende una matrice che viene applicata ad un’immagine per ottenere una seconda immagine con caratteristiche particolari. I filtri di convoluzione sono appunto quei filtri, presenti in quasi tutti i programmi di grafica, che modificano l’immagine imprimendogli alcuni effetti come per esempio la sfocatura (blur), una maggiore definizione (sharpen), etc… quasi tutti questi filtri fanno uso di matrici di convoluzione, e vedremo come creare un semplice programma in C++ che, data un’immagine in input ed una matrice di convoluzione produca l’immagine di output.

Sebbene le matrici di convoluzione, chiamate anche “kernel“, possano essere di qualsiasi dimensione, le piu’ usate sono quelle 5×5 e 3x3. In questo articolo prenderemo in considerazione solo le seconde, che sono sufficienti a creare una grande varieta’ di effetti. La matrice va applicata separatamente ad ogni canale dell’immagine (R, G, B) nel seguente modo. Supponiamo di operare esclusivamente sul canale R, visto che le operazioni sono analoghe agli altri canali, e di avere pixel con i valori indicati nella matrice a sinistra a cui vogliamo applicare la matrice di convoluzione presente a destra:

Il pixel evidenziato in rosso e’ quello su cui stiamo lavorando in questo momento, mentre la matrice a destra e’ il nostro kernel. Per applicare il filtro di convoluzione sul pixel dobbiamo immaginare di sovrapporre l’elemento centrale della matrice kernel con il pixel che stiamo considerando e di fare la somma di tutti i prodotti degli elementi sovrapposti. In poche parole dobbiamo moltiplicare gli elementi corrispondenti tra le due matrici e sommare tutti i risultati. Notate che non stiamo effettuando una normale moltiplicazione tra matrici (cioe’ un prodotto riga per colonna)!

Nel nostro caso il calcolo e’:

255*0 + 180*0 + 100*0 + 125*0 + 175*1 + 150*0 + 0*0 + 123*0 + 20*0 == 175

La matrice di convoluzione che abbiamo scelto, potrebbe essere paragonata alla matrice identita’ nel caso di un prodotto tra matrici. Come la matrice identita’ non cambia il risultato, cosi’ questa matrice  fornisce come risultato lo stesso pixel e quindi l’immagine di output rimane invariata. Ovviamente questo e’ un caso particolare, e alla fine dell’articolo vedremo alcuni degli effetti prodotti da altre matrici particolari.

Comunque, quando la matrice di convoluzione viene applicata a tutti i pixel dell’immagine il lavoro e’ terminato ed abbiamo ottenuto la nostra immagine modificata. Vediamo alcune parti del codice in C++ che trovate allegato alla fine dell’articolo. Ah, il codice fa uso, come al solito, delle librerie EasyBMP per la gestione delle BMP.

int mat[DIM][DIM];

typedef struct pixel {
	int red, green, blue;
};

Creiamo una matrice DIMxDIM (dove DIM = 3 nel nostro caso), che sara’ la nostra matrice di convoluzione, e creiamo un nostro tipo per descrivere i pixels. Dopo aver fatto inserire all’utente i 9 valori degli elementi della matrice, possiamo iniziare i calcoli. Nelle righe 38-56 (non le scrivo qua perche’ vengono formattate male) svolgiamo i calcoli veri e propri. Gli indici i e j sono le coordinate x e y del pixel che stiamo esaminando; notate che escludiamo i pixel appartenenti al bordo esterno dell’immagine semplicemente perche’ non hanno 8 pixel confinanti come tutti gli altri, e quindi verrebbe piu’ difficile applicare la matrice perche’ dovremmo escludere alcuni pixel dal conteggio; il risultato non cambia di molto.

I nuovi valori dei pixel vengono salvati in un array di oggetti pixel (il typedef che abbiamo definito poco piu’ su). Quello che ci manca è riportare questi valori in un intervallo 0…255. Sappiamo infatti che 255 e’ il valore massimo per ogni componente di un pixel, ma dall’applicazione del nostro filtro, potremmo avere (e’ spesso e’ cosi’) valori che superano questa soglia. Per fare cio’ calcoliamo la somma di tutti gli elementi della matrice di convoluzione e dividiamo tutti i valori di output per questa somma. Se dopo questa operazione ci saranno ulteriori valori > 255, li imposteremo uguali a 255, cosi’ come imposteremo a 0 quelli < 0.

Vediamo un esempio:

MATRICE DI CONVOLUZIONE 0 -1  0 -1  4  -1 0  -1  0

In questo esempio, e’ stata applicata all’immagine una matrice per individuare i bordi (edge detection). Le immagini sono piuttosto pesanti essendo BMP e quindi non compresse.

Su Internet si trovano facilmente altre matrici di convoluzione associate a risultati particolari. Ecco il codice del programma. Alla prossima.

]]> http://mindunpacked.com/2009/matrici-e-filtri-di-convoluzione/feed/ 0 http://mindunpacked.com/2009/buffer-overflow-windows/ http://mindunpacked.com/2009/buffer-overflow-windows/#comments Fri, 09 Jan 2009 14:16:01 +0000 Marco http://mindunpacked.com/?p=352 Nella parte introduttiva sull’overflow mi sembra di aver spiegato abbastanza chiaramente i fondamenti di questo tipo di errore, quasi un incubo per i programmatori. In questo articolo vedremo come sfruttare la suddetta vulnerabilità in ambiente Windows.

Il primo overflow

Passo subito alla pratica, proprio perché nel precedente articolo ho già trattato la parte teorica. Vediamo quindi un semplice programma vulnerabile all’overflow dello stack:

#include
int main(int argc, char **argv) {
char buf[20];  //inizializzo un buffer di 20 bytes
FILE* f=NULL;
int i=0;
printf("\nTest BOF");
f=fopen("input.txt","rb"); //apro il file...

while(!feof(f)) { //...e comincio a leggerne il contenuto
buf[i]=fgetc(f); //salvo i byte nel buffer
i++;
}
fclose(f); //chiudo il file
}

Si tratta di un esempio tipico di buffer overflow, dovuto all’uso incauto di un buffer nella lettura da file. Se infatti il file contiene dati per più di 20 bytes il programma andrà in crash, visualizzando il classico avviso di Windows.

Il codice, infatti, non fa altro che leggere un carattere alla volta dal file input.txt fino alla fine per poi copiarlo nella variabile buf. Naturalmente, poiché non c’è nessun controllo sulla dimensione del file, basta superare il limite del buffer per provocare la condizione di overflow. Nell’esempio, per far crashare il programma, ho inserito di proposito una stringa di 28 bytes (AAAABBBBCCCCDDDDEEEEFFFFGGGG) dove “FFFFGGGG” sono i byte eccedenti. Ma dove finiscono questi dati? Come detto la scorsa volta i dati che causano il traboccamento del buffer vanno a sovrascrivere lo stack della memoria. In questo caso, se si usa un debugger per visionare lo stato della memoria al momento dell’overflow, si noterà che il registro EIP ha assunto il valore 0×47474747 e quello EBP il valore 0×46464646, che rispettivamente equivalgono – in esadecimale – ai caratteri GGGG e FFFF.

Primi passi verso l’exploit

Modificare il registro EIP significa, in parole povere, riuscire a modificare l’esecuzione del programma, dirigendolo in una qualsiasi zona a nostro piacere. Una volta chiarito questo punto possiamo iniziare a progettare un exploit in grado di sfruttare l’overflow individuato per prendere il controllo del programma. Si procede studiando l’esecuzione del programma fino alla condizione di overflow, passo dopo passo, grazie ad un debugger. Vediamo ora la prima parte del programma. Dovete comunque tenere conto che se disassemblate un eseguibile da voi compilato l’output potrebbe differire dal mio, ciò è dovuto dalla differenza del compilatore, od anche da una versione diversa dello stesso:

00401000 push ebp //salva EBP nello stack
00401001 mov ebp,esp
00401003 sub esp,1Ch //riserva spazio per buffer
00401006 mov dword ptr [ebp-18h],0 //variabile FILE* f
0040100D mov dword ptr [ebp-1Ch],0 //variabile int i

Questa parte iniziale di codice viene generata dal compilatore e si “preoccupa” di riservare spazio nello stack utile per allocare buf (0×1C byte) e le altre variabili. Sono riportati i valori dei registri dello stack ESP e EPB prima e dopo l’esecuzione delle istruzioni. Successivamente il programma esegue la stampa a video con printf() della stringa “Test BOF”. In linguaggio assembly i prametri di una funzione vengono passati mediante salvataggio nello stack: prima della chiamata a printf() troviamo infatti un’istruzione PUSH che memorizza nello stack l’offset della stringa di testo.

00401014 push 407030h //offset stringa  “\nTest”
00401019 call 00401114 //printf()
0040101E add esp,4
...

Analizziamo ora il ciclo while che legge fino alla fine del file i byte memorizzandoli nella variabile buf:

00401033 mov dword ptr [ebp-18h], eax
00401036 mov eax, dword ptr [ebp-18h]
00401039 mov eax, dword ptr [eax-0Ch]
0040103C and ecx,10h
0040103F test ecx,ecx //test di fine file (EOF)
00401041 jne 00401061
00401043 mov edx, dword ptr [ebp-18h]
00401046 push edx
00401047 call 004010C7 //lettura da file fgetc()
0040104C add esp,4
0040104F mov ecx, dword ptr [ebp-1Ch]
00401052 mov byte ptr [ebp+ecx-14h],al //memorizza il byte in buf
00401056 mov edx, dword ptr [ebp-1Ch]
00401059 add edx,1 //incremento variabile i (i++)
0040105C mov dword ptr [ebp-1Ch],edx
0040105F jmp 00401036

l’istruzione alla riga 12 è quella che scrive nel buffer il dato letto da file mediante fget(). L’indirizzo del buffer è dato da [EBP+ECX-14h]; il valore vinere incrementato ad ogni iterazione grazie al registro ECX. E’ tuttavia la parte finale del programma, quella che segue immediatamente all’istruzione fclose(), la più interessante: viene ripristinato il valore del registro EBP e per chiudere la procedura si esegue un’istruzione di ritorno RET. Tale istruzione ha l’effetto di estrarre una word (32 bit) dallo stack e di memorizzare in eip, modificando l’indirizzo dell’istruzione corrente e spostando così il flusso di esecuzione del programma. E’ in questo momento che emergono i problemi dell’overflow e il programma raggiunge una condizione indefinita. Il ciclo while infatti, non si accorge di scrivere nel buffer più dati di quelli previsti (28 contro 20) e di conseguenza inizia a scrivere sopra lo stack alterando i valori in esso memorizzati.

00401061 mov eax, dword ptr [ebp-18h]
00401064 push eax
00401065 call 00401071
0040106A add esp,4
0040106D mov esp,ebp
0040106F pop ebp //ripristina EBP
00401070 ret //istruzione di ritorno

Tutto ciò si traduce con un errore che scatta nel momento in cui si eseguono le istruzioni POP e RET: i valori estratti dallo stack non sono quelli corretti, ma sono diventati parte dei dati letti da input; infatti, nel momento in cui si verifica il crash, ci si accorge che i registri EBP e EIP contengono i valori 0×46464646 e 0×47474747, che corrispondono proprio ai caratteri in eccedenza nel file input.txt (rispettivamente le stringe “FFFF” e “GGGG”).
Vediamo ora com’è possibile creare un exploit capace di sfruttare l’overflow del programma di esempio. Si è visto come sia possibile controllare l’andamento del programma fornendo input in eccedenza, ma è possibile andare oltre: se nell’input invece di fornire stringhe di testo, memorizziamo istruzioni assembly a nostro piacimento, possiamo iniettare il nostro codice direttamente nello stack affidato al programma e quindi modificare l’andamento del flusso d’esecuzione, dirottando il registro EIP nel punto in cui si trova il codice iniettato. L’unica difficoltà di questa fase è il calcolo degli indirizzi e degli offset di allineamento, che dovranno combaciare perfettamente per far sì che il programma ad un certo punto esegua le nostre istruzioni; analizzando la stringa di overflow ci si accorge che il valore GGGG pilota il registro EIP. La struttura dell’exploit prevede, quindi, un input di questa forma: in testa possiamo sfruttare i primi 20 byte del buffer per memorizzare il codice che vogliamo far eseguire, aiutandoci con eventuali istruzioni NOP (istruzione assembly che corrisponde a no-operation, quindi ininfluente) per allineare il codice esattamente alla dimensione di 20 byte. Seguono due word da 32 bit che corrispondono ai valori scritti dall’overflow nei registri EBP e EIP; infine, poiché per questo exploit ho pensto di visualizzare una semplice stringa di testo, memorizzeremo nella parte finale dell’input quest’ultima, terminata da 0.

Il registro EIP servirà per dirottare il flusso del programma verso l’inizio del codice da noi iniettato. Analizzando col debugger l’esecuzione del programma, si nota che il valore di EBP prima dell’overflow è 0×0012FF80, mentre lo stack usato per memorizzare i dati inizia all’offset 0×0012FF6C, che sarà proprio il punto in cui partirà il codice iniettato. Conosciamo quindi i valori delle word di EBP e di EIP, non resta che scrivere il codice da ineittare.
Come ho accennato prima, descriverò un exploit di esempio che non frà altro che stampare a schermo una stringa di testo. E’ ovvio che ci si può spingere oltre e creare i cosiddetti shellcode, ovvero del codice assembly in grado di aprire una shell sul sistema vittima, solitamente con privilegi da amministratore. Alla fine di questo articolo accennerò alla costruzione di uno shellcode, ma un argomento del genere andrebbe approfondito non poco, e richiederebbe un articolo a parte.

Ritornando all’exploit, per stampare del testo abbiamo bisogno di conoscere l’offset in cui risiede la stringa e l’indirizzo di printf(), che come si è visto prima, è localizzata a 0×00401114. Il codice assembly da iniettare sarà il seguente, per un totale di 3+5+5=13 byte.

OPCODES	ISTRUZIONE
83 EC 20	SUB ESP, 0×20
68 x1 x2 x3 x4	PUSH offset(stringa)
E8 y1 y2 y3 y4	CALL printf()

Per raggiungere i 20 bytes richiesti dall’overflow, si aggiungono 7 istruzioni NOP alla fine del codice. Gli opcodes sono i codici esadecimali che corrispondono univocamente alle istruzioni assembly; ad esempio 83 EC identifica l’istruzione SUB ESP, che seguita dal valore 0×20, sottrae 20 byte dal registro EBP. Non rimane che calcolare i valori “x1 x2 x3 x4” e “y1 y2 y3 y4” della PUSH e della CALL. L’offset della stringa di testo si calcola partendo dall’indirizzo iniziale del nostro buffer (dove inizia il codice, 0×0012FF6C) a cui si aggiungono i 28 byte del buffer, ottenendo 0×0012FF88. Per calcolare il valore di y1 y2 y3 y4 occorre invece partire dall’indirizzo della funzione printf() 0×00401114 a cui bisogna sottrarre l’offset in cui si trova l’istruzione CALL, che è dato da 0×0012FF6C+3+5+5 = 0×0012FF79. Quindi otteniamo il valore di 0×002D119B. In definitiva:

Va specificato che gli indirizzi e gli offset delle istruzioni assembly vanno scritti al contrario, cioè leggendoli da destra verso sinistra. Per creare un file di input di fatto in questo modo basta ricorrere ad un semplice programma in c++ che unisca vari pezzi dell’exploit scrivendoli su di un unico file “input.txt”. Usando il file così generato come input per il programma mostrato ad inizio articolo, l’exploit prenderà il controllo del programma visualizzando la stringa “Exploit works”. In ogni caso, al termine della funzione printf() il programma si trova in un punto indefinito, e quindi andrà in crash comunque. Ciò si può evitare aggiungendo una chiamata ad una funzione come exit().

Windows Shellcoding

Non approfondirò questo argomento, sarebbe troppo lungo e andrebbe aldilà dello scopo di questi articoli. Scrivere degli shellcode è complesso, e non cambia solo da sistema a sistema ma addirittura a seconda delle diverse versioni dello stesso. In generale uno shellcode dovrebbe aprire una shell sul sistema vittima, ma può essere usato per richiamare qualsiasi funzione di sistema approfittando dei privilegi del programma vulnerabile al buffer overflow. La difficoltà di scrivere shellcode universali è appunto dovuto al fatto che gli indirizzi delle varie funzioni cambiano a seconda del sistema. In windows è possibile risalire a tali indirizzi con un comodo programma di nome arwin. Esso permette di estrapolare l’indirizzo di una funzione presente in una determinata libreria di sistema (DLL).

C:\>arwin kernel32.dll GetProcAddressarwin
- win32 address resolution program – by steve hanna – v.01
GetProcAddress is located at 0×77e7b332 in kernel32.dll

In questo caso siamo riusciti a capire l’indirizzo della funzione GetProcAddres, che fra l’altro è molto utile per risalire a qualsiasi altra API di sistema. Il codice da iniettare dovrà essere scritto usando gli indirizzi così ricavati, avrete quindi capito che con uno shellcode si può fare qualsiasi cosa, capacità di programmazione assembly permettendo.