posts - 644, comments - 1989, trackbacks - 137

My Links

News

Raffaele Rialdi website

Su questo sito si trovano i miei articoli, esempi, snippet, tools, etc.

Archives

Post Categories

Image Galleries

Blogs

Links

Codice managed e nativo: documentazione, usabilità e obfuscation

Ecco un titolo che frulla insieme argomenti da riempire un paio di libri.

Periodicamente mi trovo a rimettere le mani su codice C++. È normale perché ogni linguaggio+runtime (anche C++ necessita di un runtime) ha un suo campo di applicazione che dipende dai requisiti del progetto... nulla di nuovo.

E infatti C++ nativo (non CLI) è tutt'ora lo strumento preferibile per l'estendibilità della shell, IE, WMI, DirectX, mmc e molto altro ancora.

Cari programmatori managed, una documentazione come quella che avete a disposizione oggi sarebbe stata il paradiso terrestre per chi ha lavorato / lavora con ATL, MFC, Win32, C++ e tutto quello che ci sta intorno. Questi sono strumenti potenti, estremamente efficaci, collaudati e robusti ma anche semplici da abusare e perciò tramutare un progetto in un disastro.

Se guardo alla complessità dei sistemi che ho realizzato in 9 anni di programmazione managed, sono assolutamente certo che con linguaggi+runtime nativi non avrei potuto costruire sistemi altrettanto complessi dal punto di vista architetturale.

C'è invece un enorme, gigantesco, pantagruelico gap tra i tecnicismi del mondo managed e quelli del mondo nativo: nel mondo nativo tutto si giocava sulla comprensione e l'applicazione del tecnicismo, sull'hack, sull'algoritmo che eseguiva dei tweak nei meccanismi standard; nel mondo managed il tecnicismo è quasi sempre poca cosa, l'architettura è regina, il numero di layer cresce a dismisura (entro certi limiti è buona cosa), le ambiguità su una tecnologia sono estremamente più basse.

Ed è qui che si gioca la partita dell'obfuscation, cioè della protezione del software.
Nell'era nativa la protezione degli hack e dei tweak erano il maggior valore del software. Ricordo ancora che debuggando i primi viewer di immagini per SuperVGA sotto DOS ho capito come superavano il limite dei 64K per caricare su più banchi le immagini ad alta risoluzione. (Non si scandalizzino i più giovani, ma nell'era pre-80386 la memoria era segmentata e la memoria grafica era "solo" 64K, quindi come caricare immagini più grosse?)

Nell'era managed, guardi come funziona un software e l'architettura è "in chiaro" non perché puoi usare reflector ma perché è evidente come funziona già da come vengono installati gli assembly o guardando una traccia di rete. Buona parte del codice managed che scriviamo "traspare" ad un utente esperto o al power user equipaggiato di ProcMon e vari altri tool. Se poi si passa a Reflector tutto è più chiaro ma non sono daccordo che sia solo il sorgente a rendere tutto così palese.

La complessità del codice managed ha come side effect il fatto di essere tanto e di doverlo conoscere bene per poter essere usato. Se ti do un milione di righe di sorgente è come non averlo. Il tempo che ci metto a capirlo forse non vale neppure il gioco. E questo è il motivo per cui spesso dico che il sorgente non è il valore del progetto.

È chiaro che non si può generalizzare e se scrivo una applicazione di calcolo ingegneristico che in mille righe risolve problemi mai visti prima, ecco che la sua protezione diventa strategica. Ma chi pensa che il codice C++ sia protetto by design si sbaglia di grosso. Ho letto e debuggato kilometri di codice assembler, i compilatori sono abbastanza "stupidi" da scrivere codice assembler con dei pattern, che una volta riconosciuti permettono di capire molto di più di quanto si creda (Esempio: ECX è il registro usato per il this di una classe C++). Ci sono poi applicazioni come DASM (un disassemblatore), il famoso debugger IDA pro che fa veri miracoli, o ancora gli analizzatori di codice PE (il formato di exe e dll) che permette di fare un guessing della marca e della versione del compilatore usato.

La transizione dai tecnicismi di C++ alla complessità "verticale" delle applicazioni managed spiega anche il calo di interesse nel proteggere il codice compilato. L'obfuscation del codice può essere una necessità ma non ritengo che sia più largamente sentita come un tempo.

Print | posted on Friday, September 25, 2009 4:42 PM |

Feedback

Gravatar

# re: Codice managed e nativo: documentazione, usabilità e obfuscation

Concordo con quello che dici Raf, ma sulla parte dell'obfuscation farei un'aggiunta: almeno dalla mia esperienza, più che proteggere chissà quali algoritmi, ciò per cui può tornare utile l'obfuscation o tecniche affini è per impedire che il software venga utilizzato a scrocco (completamente, o in un numero di licenze superiore a quello per cui si è pagato), e anche se una protezione totale è sicuramente irraggiungibile, già evitare che il primo che arrivi in pochi minuti capisca con reflector o altri metodi semplici come aggirare le chiavi di attivazione, già può essere qualcosa
9/25/2009 6:24 PM | Stefano
Gravatar

# re: Codice managed e nativo: documentazione, usabilità e obfuscation

@Stefano. Nessun sadico motivo, l'opzione di ritornare alla segmentazione è impraticabile.
- dai manuali Intel non mi viene proprio in mente che sia possibile eseguire una segmentazione in user mode con il virtual mode attivato. La modifica dei descrittori è possibile solo in kernel mode ovviamente
- in Windows ci sono diversi sistemi per usare più memoria dei 2GB/3GB di user mode disponibili. Ma non è memoria disponibile in modo lineare e quindi è comunque una rogna.
- A 32 bit rimane il problema della frammentazione che provoca gli out of memory solo perché non è disponibile memoria contigua (cosa che i Garbage Collector come quello del Framework almeno in parte minimizzano, mentre C++ classic non può farci nulla).
- le cpu a 64 bit ci sono da un pezzo e costano pochissimo, quindi non vedo il problema dei costi. Non è comparabile quello che facciamo fare alle applicazioni oggi rispetto ad un tempo. E i vantaggi sono tangibilissimi anche per applicazioni di tipo base (se sono fatte bene ovviamente la differenza conta)
10/4/2009 2:02 AM | Raffaele Rialdi

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 2 and 8 and type the answer here:

Powered by:
Powered By Subtext Powered By ASP.NET