Giro una notizia che sta passando abbastanza in sordina ma che dovrebbe fare immediatamente il giro del mondo.
Microsoft ha rilasciato l’SDK di U-Prove di cui avevo già parlato in maniera flash in precedenza. La parte più interessante è questa:
It is made available under the BSD open-source license.
Vittorio Bertocci aka Vibro.Net ha intervistato Stefan Brands, il ricercatore dietro questa importante innovazione. L’intervista è estremamente godibile per gli appassionati dell’argomento cryptografia; Vittorio la definisce in una parola sola come cryptopr0n.
Enjoy!
P.S. sempre a proposito di privacy le scuse pubbliche di Google sulla questione Buzz sono esilaranti. The Onion è un giornale satirico, però l’esagerazione caricaturale dell’articolo è davvero minima.
Mentre giochicchiavo con alcuni database engine scritti interamente in C#, mi sono imbattuto in una spettacolare manifestazione di un baco scoperto già nel 1976. Trentaquattro anni, quasi più vecchio di me, eppure…
Gli aspetti interessanti sono due. Quello storico, il cui punto di partenza è questo articolo su Wikipedia. Quello tecnico contenuto in questo blog post di Craig Freedman.
La manifestazione del baco che ho incontrato io è piuttosto banale:
CREATE TABLE TEST(Foo VARCHAR(10))
INSERT INTO TEST VALUES (‘Bar’)
INSERT INTO TEST SELECT * FROM TEST
Un database che funzioni dovrebbe contenere due righe identiche. Uno scassato… non lo ferma più nessuno! 
-quack
Compro una scheda hardware di cui mi 
riprometto di condividere maggiori dettagli e che viene venduta in due bundle diversi.
1. Scheda + Applicazione A
2. Scheda + Plugin per applicazione B
Siccome mi interessa tantissimo il secondo bundle, comincio ad informarmi su come comprarlo. Sul mercato americano non è mai comparso. Sembra disponibile forse in Giappone ed è in vendita al pubblico in Australia, ma il negozio online non sembra voler spedire verso gli Stati Uniti.
Navigo sul sito dell’azienda che produce la scheda scoprendo che il bundle B è abbastanza supportato, infatti è possibile scaricare un aggiornamento che però richiede che la versione precedente sia già attivata. È giusto, non mi oppongo anche se mi da un po’ fastidio il fatto che non riesca a poter comprare quello che voglio. Scompatto ed installo l’aggiornamento e scopro l’esistenza di una fantomatica libreria “ApplicazioneA.Dll”, ovvero il plugin venduto da una società terza usa codice di chi ha scritto l’applicazione A in licenza per poter implementare il plugin per B. Ad occhio e croce il formato del codice seriale, 6 gruppi alfanumerici di quattro cifre, sembra essere identico con quello dell’Applicazione A. Nel frattempo scopro l’esistenza di un’offerta limitatissima per il bundle numero 1. Mi azzardo, provo, ricevo.
Tento di usare il PID dell’applicazione A con il plugin B ma non funziona. Ogni volta che il plugin viene lanciato parla con un server internet per chiedere se la chiave è valida. La cosa mi infastidisce tanto, saranno pure cacchi miei quando e come voglio lanciare l’applicazione/plugin? Ci attacco un proxy, guardo la connessione HTTP (che tapini, manco usare SSL per questo tipo di dialogo) e sorpresa il plugin B parla con i server dell’applicazione A.
Mi incazzo, hanno abbondantemente gonfiato le siffatte ciufole. È ora di adattare il software alle _MIE_ esigenze. Tento di carpire come comunicano client e server sperando di usare il trucco del proxy ma c’è bisogno di una attivazione riuscita per tentare un replay attack. Guardare codice in assembler e cercare di fare il reverse engineering di quale sia il messaggio di sblocco non è più alla mia portata; tra l’altro penso che un replay attack non è il modo più semplice per riattivare il software qualora dovesse servire. Tento disperatamente la patch binaria, non saranno mica così pirla da non aver perlomeno da qualche parte “firmato” il codice tramite una banale checksum.
Trovo un pezzo di codice che fa più o meno questo:
int EAX = 0;
EAX = Call_ProceduraMisteriosaX();
if (EAX == 0)
{
return 0;
}
EAX = Call_ProceduraMisteriosaY();
if (EAX == 0)
{
return 0;
}
EAX = Call_GetPointerForError(EAX);
return EAX;
Sostituisco i due if(EAX == 0) con return 0; in assembler equivale a sostituire TEST EAX, EAX con XOR EAX, EAX. Ovvero rimpiazzare due volte l’opcode 33 (TEST) con l’opcode 85 (XOR), cambiando lo stato di 10 bit in tutto su una ventina di milioni.
Sono scettico ma funziona molto bene.
La coscienza? È a posto. Il prezzo dei due bundle è identico. L’applicazione A non mi interessa. Ho cercato in tutti i modi di comprare il secondo bundle senza successo; e dal punto di vista economico non mi sembra di danneggiare nessuno, visto che la distribuzione degli introiti dei due bundle sembra essere la stessa. E a suggerirlo c’è il fatto che l’azienda di B distribuisca un’applicazione a riga di comando simile all’applicazione A in maniera totalmente gratuita. Sinceramente certe manovre distributive tafazzi-style mi lasciano completamente allibito; nel frattempo s’è fatta ora di tornare al lavoro di tutti i giorni nel bright side.
-quack
Se c’è una attività lavorativa che mi piace più dello scrivere codice è quella di “rimuovere codice” extra. Ecco una nuova versione dei “metodi dinamici di delegazione” che ho scoperto mentre per lavoro mi documentavo sulla libreria degli ET della versione 4.0 del framework .net:
private TypeConstruct constructor;
delegate object TypeConstruct();
private static TypeConstruct CreateConstructor(Type t)
{
NewExpression call = Expression.New(t);
Expression<TypeConstruct> lambda = Expression.Lambda<TypeConstruct>(
Expression.Convert(call, typeof(object)));
return lambda.Compile();
}
Il codice qui sopra a differenza del precedente è compatibile anche con i setting di sicurezza estremamente aggressivi del mio Web Hoster pur mantenendo lo stesso livello di performance. Devo ammettere però che ho molta difficoltà nell’afferrare tutti i dettagli di quanto succede sotto il cofano. Però funziona…
-quack
Pochi giorni fa mi sono riscontrato nel cosidetto Heisenbug perfetto. Di solito gli Heisenbug hanno a che fare con il multi-threading circostanza per cui aggiungere qualche breakpoint al codice sfasa il timing dell’applicazione e per tanto potrebbe causare la scomparsa di un baco sotto osservazione. Nel mio caso non c’era nessun multithreading, ma bastava semplicemente “osservare” il comportamento dell’oggetto misterioso per deviarne il flusso di esecuzione. Ridotto al minimo l’Heisenbug è descritto qui sotto:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Heisenbug
{
class MyClass
{
bool here;
public override string ToString()
{
string result = here.ToString();
this.here = true;
return result;
}
public MyClass()
{
this.here = false;
// put a breakpoint on the following line
// and add 'this' to the watch window and
// then execute
Console.WriteLine(this.ToString());
}
}
class Program
{
static void Main(string[] args)
{
MyClass c = new MyClass();
Console.WriteLine(c.ToString());
}
}
}
Normalmente l’applicazione scrive False-True sulla console. Se invece si aggiunge un breakpoint nella riga del costruttore indicata e si osserva appunto l’oggetto appena instanziato il risultato diventa True-True. La cosa non è stata banale da individuare perché il tutto era offuscato da qualche altro centinaio di righe di codice e parlandone con il collega pazzo con la capigliatura più caotica della mia ne è nata una questione filosofica: ma il debugger può permettersi davvero di invocare metodi mentre un oggetto è ancora in costruzione? Girerò la domanda a quelli del team di Visual Studio per sapere se il comportamento è documentato (prescritto) da qualche parte.
-quack
Update:
Dalla regia mi suggeriscono che questo comportamento può essere disabilitato ed il valore di default in effetti makes sense.
VS – Developer 1-0 e palla al centro
