Rezumat teza - Universitatea Tehnic?

FACULTATEA DE ELECTRONICǍ, TELECOMUNICAŢII ŞI TEHNOLOGIA INFORMAŢIEI
mat. Petrean Liviu
TEZĂ DE DOCTORAT
- REZUMAT -
Securitatea Aplicaţiilor de Calculator – Contribuţii la Protecţia
Fişierelor Executabile
Comisia de evaluare a tezei de doctorat:
1
Conducător ştiinţific,
Prof.dr.ing.Gavril Toderean
PREŞEDINTE: - Prof.dr.ing. Tudor Palade, Prodecan, Universitatea Tehnică din Cluj-Napoca
MEMBRI: - Prof.dr.ing. Gavril Toderean, Conducător ştiinţific, Universitatea Tehnică din
Cluj-Napoca
- Prof.dr.ing. Ionel Jian, Referent, Universitatea “Politehnica” din Timişoara
- Prof.dr.ing. Nicolae Tomai, Referent, Universitatea “Babeş-Bolyai”, Cluj-Napoca
- Conf.univ.dr. Ştefan Oniga, Referent, Universitatea de Nord din Baia Mare

Listă de abrevieri, simboluri şi denumiri
API = Application Programming Interface, seturi de cod puse la dispoziţia programatorilor de către
sistemul de operare sau diferitele medii de programare;
BMS = Bit/Byte Most Significant, cel mai semnificativ bit al unui octet sau cel mai semnificativ octet al
unui cuvânt;
Cracker = persoană care se ocupă cu spartul parolelor, modificarea codului fişierelor executabile şi
publicarea acestor modificări pe internet;
Cracking = operaţia de spargere a unei parole sau de modificare a codului unui fişier executabil;
DLL = Dynamic Link Library, fişiere librărie ale sistemelor de operare Microsoft Windows importate la
rularea fişierelor executabile;
EAT = Export Address Table, tabela de exporturi a unui fişier executabil;
ENT = Export Name Table, tabela de exporturi după nume a unui fisier executabil;
EOT = Export Ordinal Table, tabela de exporturi după număr ordinal a unui fişier executabil;
IAT = Import Address Table, tabela cu adresele importurilor unui fişier executabil;
PE = Portable Executable, fişier executabil, cu extensia .EXE, .DLL sau .OCX
2

CUPRINS
Pagina
Teza Rezumat
1. Introducere………………………………………………………………….......................... 3 5
1.1 Obiective de cercetare…………………………………………………............................ 3 5
1.2 Structura tezei..................................................................................................................... 4 6
2. Stadiul actual al securităţii aplicaţiilor de calculator........................................................... 6 8
2.1 Situaţia actuală a pirateriei aplicaţiilor de calculator......................................................... 6 8
2.2 Părţi vulnerabile ale unui fişier executabil......................................................................... 7
2.3 Unelte folosite de crackeri.................................................................................................. 9
2.4 Ollydebugger………………………………………………………….............................. 11
2.5 Soluţii actuale de protecţie a aplicaţiilor de calculator...................................................... 12 9
2.5.1 ASProtect................................................................................................................ 14
2.5.2 Execryptor............................................................................................................... 14
2.5.3 Molebox.................................................................................................................. 15
2.5.4 Enigma Protector………………………………………………………................ 15
2.5.5 SVKP………………………………………………………… …………………. 16
2.5.6 ExeWrapper……………………………………………………………................ 16
2.5.7 Themida…………………………………………………………………………...17
2.5.8 Private Exe Protector...............................................................................................17
2.6 Concluzii............................................................................................................................17 10
3. Fundamente teoretice de bază..................................................................................................20 12
3.1 Structura şi parametrii de bază ai unui fişier executabil......................................................20 12
3.2 Secţiunea de exporturi a unui fişier executabil....................................................................25
3.3 Secţiunea şi directorul de importuri a unui fişier executabil...............................................28
3.4 Setul de instrucţiuni 8086....................................................................................................31
3.5 Formatul instrucţiunilor în limbaj de asamblare.................................................................32
3.6 Transformări la nivel de limbaj de asamblare.....................................................................35
4. Proiectarea şi dezvoltarea unui program de protecţie a fişierelor executabile......................39 15
4.1 Implementarea componentei packer....................................................................................40
4.1.1 Salvarea unei copii de siguranţă a fişierului protejat................................................40
4.1.2 Alocarea spaţiului de memorie pentru fişierul protejat............................................41
4.1.3 Identificarea fişierului executabil şi citirea parametrilor de bază ai acestuia...........42
4.1.4 Eliminarea tabelei de importuri originale.................................................................43
4.1.5 Criptarea numelor librăriilor DLL şi ale funcţiilor Windows API...........................43
4.1.6 Criptarea secţiunilor fişierului executabil utilizând cod polimorfic.........................44
4.1.7 Adăugarea unei secţiuni noi fişierului executabil protejat.......................................50
4.1.8 Construirea tabelei de importuri a componentei packer...........................................54
4.2 Implementarea componentei depacker................................................................................55
4.2.1 Apelul funcţiilor Windows API din componenta depacker.....................................55
4.2.2 Saltul la punctul de intrare al fişierului executabil protejat.....................................56
4.2.3 Iniţializarea şi reconstruirea tabelei de importuri cu componenta depacker............56
4.2.4 Criptarea codului componentei depacker a programului protector......................... 57
3

4.2.5 Obfuscarea statică a codului componentei depacker...................................................58
4.2.6 Obfuscarea dinamică a codului componentei depacker...............................................60
4.3 Concluzii.................................................................................................................................61 16
5. Algoritmi de criptare a numerelor seriale..................................................................................63 17
5.1 Noţiuni matematice de bază....................................................................................................63
5.2 Algoritm de criptare cu două matrice cheie............................................................................67
5.3 Rezultatele obţinute în uma criptării cu două matrice cheie...................................................70
5.4 Generarea matricelor cheie.....................................................................................................73
5.5 Algoritm de criptare cu o singură matrice cheie.....................................................................76
5.6 Rezultatele obţinute în urma criptării cu o singură matrice cheie...........................................79 17
5.7 Utilitatea algoritmilor de criptare cu matrice...........................................................................82 20
6. Evaluarea performanţelor fişierelor executabile protejate cu programul prezentat în această
teză....................................................................................................................................................83 21
6.1 Teste de performanţă...............................................................................................................84 21
6.2 Test de securitate al metodelor de obfuscare..........................................................................86 23
6.3 Performanţele implementării algoritmilor de criptare cu matrice.......................................... 88 25
7. Concluzii......................................................................................................................................89 26
7.1 Concluzii finale.......................................................................................................................89 26
7.2 Contribuţii...............................................................................................................................91 28
7.3 Direcţii de cercetare ulterioară................................................................................................94 31
Bibliografie......................................................................................................................................95 32
Anexe..............................................................................................................................................100
Anexa 1........................................................................................................................................100
Anexa 2........................................................................................................................................105
Anexa 3........................................................................................................................................110
Anexa 4........................................................................................................................................130
Listă de tabele..................................................................................................................................135
Listă de figuri...................................................................................................................................135
Listă de abrevieri şi denumiri..........................................................................................................136
Listă de publicaţii............................................................................................................................136
Curriculum Vitae.............................................................................................................................138 33
4

1. Introducere
1.1 Obiective de cercetare
Scrierea de programe şi aplicaţii de calculator reprezintă un domeniu complex care ia amploare an de
an odată cu dezvoltarea mediilor de dezvoltare integrate de la diferite companii precum Microsoft şi
Borland, actualizarea limbajelor de programare existente şi apariţia unor limbaje noi.
Complexitatea scrierii de programe de calculator rezultă din designul complex şi execuţia complexă a
fiecărui program. Se crează astfel dificultăţi pentru programatori şi inevitabil, apar erori. În domeniul
securităţii software, suma acestor erori poartă numele de vulnerabilitate software, [24]. Lucrarea de faţă
îşi propune analiza critică a acestor vulnerabilităţi şi diminuarea lor maximă, crescând astfel fiabilitatea şi
nivelul de securitate al programelor de calculator.
Problema vulnerabilităţii programelor de calculator este discutată în numeroase lucrări unde se
enumerează erori şi se propun soluţii dar cu prea puţine exemple practice care să vină în ajutorul
programatorilor. Un program vulnerabil produce o scurgere de informaţii către un utilizator neautorizat
care apoi face publice aceste informaţii şi compromite întregul program [20], [21].
Rezolvarea eficientă a problemei vulnerabilităţii programelor de calculator presupune un studiu
amănunţit al naturii şi comportamentului fiecărui program. Datorită volumului mare de aplicaţii
comerciale şi medii de programare existente azi, soluţia problemei depinde de un punct comun al
acestora. Acest punct comun îl reprezintă compilarea şi apoi execuţia fiecărui program în limbaj de
asamblare la nivel de microprocesor.
Studiul codului de asamblare [1], [2], [10], generat de fiecare mediu de dezvoltare este punctul de
început în rezolvarea problemei vulnerabilităţii. În urma acestui studiu se pot extrage informaţii în
legatură cu comportamentul, execuţia fiecărui program şi informaţii despre securitatea programului.
Soluţia propusă în această teză constă în ascunderea cât mai eficientă a informaţiilor din interiorul unui
program executabil şi ascunderea logicii programului în sine. S-au fixat şi s-au atins următoarele
obiective:
Prezentarea stadiului actual al securităţii programelor de calculator;
Studiul şi determinarea unor puncte vulnerabile comune ale programelor de calculator;
Studiul amănunţit al structurii unui fişier executabil, citirea parametrilor şi modificarea
acestora;
Propunerea unei soluţii pentru ascunderea logicii unui program de calculator în urma
aplicării de transformări la nivel de instrucţiuni în limbaj de asamblare (polimorfism şi
transformări metamorfice);
Implementarea unei soluţii pentru diminuarea vulnerabilităţii programelor de calculator
prin dezvoltarea unei aplicaţii de protecţie a fişierelor executabile, în limbaj de asamblare
cu ajutorul mediului integrat de dezvoltare, distribuit gratuit, Winasm Studio;
Elaborarea unei scheme de protecţie originală bazată pe criptarea cu una sau două matrice
implementând transformări neliniare asupra elementelor matricelor de stare;
Analiza rezultatelor obţinute cu programul de protecţie şi posibilităţi de îmbunătăţire ale
acestuia.
5

1.2 Structura tezei
Teza este împărţită în 7 capitole după cum urmează:
Capitolul 1, Introducere prezintă obiectivele de cercetare şi oferă o privire de ansamblu asupra
celorlalte capitole ale tezei.
Capitolul 2, Stadiul actual al securităţii aplicaţiilor de calculator prezintă un studiu efectuat
asupra situaţiei actuale a pirateriei programelor de calculator şi enumerează soluţii existente pentru
protecţia acestora. Studiul relevă faptul că pe lângă metodele legislative impuse de guvernele ţărilor cu o
piraterie software ridicată se impun metode profesionale de protecţie a programelor. Astfel, în cadrul
aceluiaşi capitol, se analizează părţile vulnerabile ale unui fişier executabil şi se face o trecere în revistă a
metodelor de protecţie existente. Se prezintă un studiu efectuat asupra a aproximativ 400 de programe
comercializate pe internet, în versiuni shareware sau time-trial, în urma căruia rezultă că majoritatea
companiilor de software nu utilizează metode de protecţie a codului asamblare. Acest lucru scoate în
evidenţă motivul principal care a dus la redactarea acestei teze şi anume elaborarea de soluţii noi de
protecţie a programelor de calculator şi optimizarea celor existente. Tot în cadrul acestui capitol se
enumerează programele utilizate de crackeri şi cele mai utilizate programe de protecţie automată a
fişierelor executabile.
Capitolul 3, Fundamente teoretice de bază prezintă în primul rând structura detaliată a unui fişier
executabil. Deoarece teza are ca obiectiv protecţia programelor de calculator, se impune o cunoaştere
amănunţită a tuturor structurilor care compun un fişier executabil. Astfel, sunt enumerate structurile antet
DOS Header şi PE Header, tabelul de secţiuni şi apoi secţiunile unui fişier executabil. Se prezintă
membrii fiecărei structuri, tipul lor de date şi informaţia conţinută în fiecare membru. Din antetul DOS
Header sunt amintiţi membrii e_magic şi e_lfanew care stau la baza identificării unui fişier executabil.
Din antetul fişierului executabil PE Header se amintesc membrii Signature, folosit tot la identificare,
AddressOfEntryPoint care conţine adresa primei instrucţiuni care se execută din fişierului executabil,
ImageBase care conţine adresa paginii de memorie unde este încărcat fişierul executabil de către sistemul
de operare, SectionAlignment care conţine valoarea de aliniere a secţiunilor fişierului în memorie,
FileAlignment care conţine valoarea de aliniere a secţiunilor în fişier, SizeOfImage care conţine
dimensiunea totală a fişierului executabil în memorie şi SizeOfHeaders care conţine adresa offset a primei
secţiuni a fişîerului executabil. Apoi se amintesc vectorul DataDirectory şi secţiunile de exporturi şi
importuri a unui fişier executabil.
Deoarece soluţiile de protecţie ale fişierelor executabile laborate în cadrul acestei teze sunt
implementate în limbaj de asamblare, se face o trecere în revistă a setului de instrucţiuni 8086 şi a
formatului acestor instrucţiuni. Capitolul se încheie cu noţiunile teoretice necesare efectuării de
transformări asupra instrucţiunilor în limbaj de asamblare, prin exemple.
Capitolul 4, Proiectarea şi dezvoltarea unui program de protecţie a fişierelor executabile
prezintă punerea în practică a noţiunilor teoretice amintite în capitolul 3. Sunt prezentate componentele de
bază ale unui program de protecţie automată, definite ca packer şi depacker. Se prezintă implemetarea
acestor componente în limbaj de asamblare sub mediul de dezvoltare integrată Winasm Studio care
integrează compilatorul MASM (Microsoft Macro Ass embler) şi operaţiile efectuate. Astfel, se trec în
revistă operaţiile de identificare a unui fişier de tip executabil prin citirea parametrilor din antetele DOS şi
PE, operaţiile de citire şi afişare a parametrilor amintiţi în capitolul 3, alocarea de memorie pentru fişierul
executabil protejat, adăugarea de secţiuni noi fişierului executabil protejat, eliminarea unor membrii din
structurile fişierului executabil sau înlocuirea acestora şi se prezintă soluţii originale de criptare a
secţiunilor de date şi cod ale fişierului executabil protejat. Se prezintă o metodă originală de redirecţionare
şi reconstruire a tabelei de importuri a fişierelui executabil protejat şi se defineşte metoda de criptare cu
6

cheie incrementată a codului asamblare. Se definesc metodele de obfuscare statică şi dinamică a codului
asamblare utilizate împreună cu rutine poli/metamorfice de criptare a codului asamblare la execuţie. Se
testează fiabilitatea programului implementat prin protecţia programelor de calculator selectate în cadrul
capitolului 2, se urmăreşte dacă programul intră în conflict cu sistemul de operare sau programe antivirus
şi se compară cu alte programe asemănătoare rezultatele trecându-se într-un tabel.
Capitolul 5, Algoritmi de criptare a numerelor seriale prezintă soluţii originale implementate în
cadrul acestei teze şi menite să vină în ajutorul programatorilor de rutine de protecţie a programelor de
calculator. Se extinde algoritmul de criptare Hill cu ajutorul noţiunii de matrice aritmetic echivalente, din
algebra liniară. Se trec în revistă noţiuni teoretice care se pun apoi în practică făcând o analiză a
rezultatelor obţinute în urma aplicării fiecărui algoritm elaborat. Se defineşte noţiunea de matrice de stare.
Se amintesc o categorie de transformări neliniare din algebra computaţională, precum transformări
pseudo-Hadamard, efectuate asupra elementelor matricei de stare, în scopul creşterii nivelului de
complexitate a algoritmilor liniari prezentaţi. Capitolul se încheie cu prezentarea utilităţii algoritmilor de
criptare elaboraţi. Astfel, algoritmii se vor aplica textului care formează numărul serial iar în final se
aplică o funcţie hash care împarte şirul criptat în blocuri şi efectuează operaţii de control asupra acestora.
Capitolul 6, Evaluarea performanţelor fişierelor executabile protejate cu programul prezentat
în această teză prezintă testele de performanţă, securitate şi funcţionalitate a metodelor originale de
protecţie implementate în programul protector şi a algoritmilor de criptare a numerelor seriale. Se fac teste
de comparaţie a dimensiunii fişierului înainte şi după protecţie, se fac teste de viteză de execuţie a
fişierului înainte şi după protecţie, se defineşte întârzierea de decriptare şi se măsoară, rezultatele
trecându-se în tabel. Se defineşte noţiunea de buffer de criptare şi se fac teste de performanţă a fişierului
executabil protejat în funcţie de dimensiunea acestui buffer.
Capitolul 7, Concluzii prezintă concluziile finale, contribuţiile aduse în acestă teză şi direcţiile
ulterioare de cercetare.
Secţiunea Bibliografie enumerează referinţele bibliografice utilizate în această teză.
Anexele lucrării conţin toate articolele publicate la sesiuni de comunicări ştiinţifice internaţionale, pe
perioada elaborării tezei, şi codul sursă al programului de protecţie automată a fişierelor executabile
dezvoltat în capitolul 4.
7

2. Stadiul actual al securităţii aplicaţiilor de calculator
2.1 Situaţia actuală a pirateriei aplicaţiilor de calculator
În urma compilării unui program cu ajutorul oricărui mediu de programare existent rezultă un
fişier de tip executabil ( Portable Executable) cu extensia .EXE, .DLL sau .OCX, [4], [5]. Analiza şi
modificarea acestor fişiere este posibilă cu ajutorul unor programe speciale numite debuggere care
afişează întregul cod al programului în limbaj asamblare. Dintre debuggerele cel mai des utilizate
amintim: IDA Pro, Ollydebugger, Win32Dasm, TRW (pentru Windows 98, NT/XP) şi Softice (pentru
Windows 98). Programele de tip debugger sunt proiectate şi implementate pentru a veni în sprijinul
programatorilor la depanarea erorilor de execuţie, unul din marile avantaje oferite de acestea fiind
posibilitatea executării programului, instrucţiune cu instrucţiune. Debuggerelor li se alatură şi
dezasambloarele care constituie un set de programe dedicate depanării programelor scrise în limbaje de
programare de nivel înalt cum ar fi Visual Basic sau Delphi, şi care fac posibilă reconstruirea completă a
codului sursă al programului analizat. Menite să vină în ajutorul programatorilor, debuggerele utilizate de
către persoane neautorizate pentru analiza codurilor programelor de calculator se transformă în arme
eficiente folosite la modificarea şi reducerea fiabilităţii programelor. Examinarea şi modificarea unui
fişier executabil cu ajutorul unui debugger se numeşte reverse engineering sau cracking. Persoanele care
modifică fişiere executabile şi le utilizează după bunul plac se numesc reverse engineers sau crackeri.
Un dezavantaj major pentru crackeri este faptul că debuggerele, deşi dezvăluie întregul cod
asamblare al programului, nu oferă nimic despre codul sursă, acesta fiind imposibil de generat dintr-un
simplu fişier executabil. Dintre alte utilitare care oferă modificarea fişierelor executabile mai amintim şi
editoarele hexazecimale.
Pentru creşterea fiabilităţii fişierelor executabile se impune implementarea unor metode de
securitate care împiedică încărcarea şi analiza acestora într-un debugger, [2], [3], [9], [10]. Dacă
încărcarea în debugger se realizează totuşi cu succes, trebuie ascunsă logica programului prin metode
specifice limbajului de asamblare sau limbajului C. Aceste metode sunt optimizate în această teză
împreună cu alte soluţii actuale de securitate şi se elaborează metode noi pentru obţinerea de fişiere
executabile robuste, fiabile, care să reziste celor mai avansate tehnici de cracking din pirateria de
programe actuale.
Pirateria aplicaţiilor de calculator continuă să tulbure industria de calculatoare, producând pierderi
financiare enorme an de an, [20]. Pentru a înţelege mai bine efectele pirateriei şi ale cracking-ului, se pot
citi rapoartele online ale societăţii internaţionale Business Software Alliance (BSA) începând cu 23 Mai
2006. Acestea dezvăluie că 35% din programele instalate pe calculatoare in 2005 au fost piratate
înregistrând o pierdere globală pentru companiile producătoare de software de 34 miliarde de dolari, cu
1,4 miliarde de dolari mai mult decât în 2004. În 2008, valoarea programelor utilizate ilegal în întreaga
lume a atins bariera de 59 miliarde de dolari şi până în 2011 a crescut cu 11 procente.
Acelaşi raport relevă că SUA şi Noua Zeelandă sunt ţările cu pirateria cea mai redusă, la polul
opus aflându-se Vietnam, Zimbabwe şi Pakistan. Un fapt îmbucurător care reiese din raportul BSA este că
în China, Rusia, India, Orientul Mijlociu şi Europa Centrala şi de Est pirateria a scăzut ca urmare a
măsurilor luate de guvernele ţărilor şi zonelor respective.
Cercetările individuale efectuate în ultimii trei ani asupra fişierelor executabile a sute de aplicaţii
comercializate astăzi prin intermediul internetului relevă faptul că din fişierele examinate doar 50% sunt
protejate împotriva crackerilor, cealaltă jumătate nefiind protejată deloc sau doar cu ajutorul unor
algoritmi uşor de depăşit prin metode elementare.
8

Ce metode există pentru a combate pirateria, înafara celor legislative? Cum pot să-mi protejez
produsul cât mai bine? Sunt doar două din întrebările pe care şi le pun producătorii de programe de
calculator. Răspunsul este dobândirea de cunoştinţe avansate de limbaj de asamblare şi de structură a unui
fişier executabil şi aplicarea acestor cunoştinţe la protecţia părţilor vulnerabile ale fişierelor executabile
obţinute.
2.5 Soluţii actuale de protecţie a aplicaţiilor de calculator
Pentru orice mecanism de protecţie al unei aplicaţii de calculator, cheia este verificarea autenticităţii
produsului [4], [5]. Producătorul trebuie să ştie dacă persoana care foloseşte programul este sau nu cea
sau cel care se pretinde a fi şi dacă acea persoană este autorizată să folosească produsul. În acest context
prin persoană se înţelege nu numai utilizatorul ca atare ci şi calculatorul sau mediul pe care este păstrată
copia înregistrată a aplicaţiei. Astfel, putem deosebi două tipuri de protecţie folosite de producătorii de
programe:
- protecţie care se bazează pe cunoaştere (a unei parole, număr serial, etc);
- protecţie care se bazează pe posesia (unui disc cheie, a unei documentaţii, etc)
Protecţia care se bazează pe cunoaşterea unei parole anume, se dovedeşte a fi ineficientă dacă
posesorul parolei se decide să o facă cunoscută altor utilizatori, sau mai mult, public. În acest caz orice
persoană care cunoaşte parola poate folosi aplicaţia. Dacă acest tip de protecţie se dovedeşte a fi
ineficient, de ce se mai foloseste de către producatori? Răspunsul e simplu: producătorii îşi protejează
proprietatea intelectuală împotriva atacurilor prin “forţă brută”. De asemenea, acest tip de protecţie este
ideal pentru firme şi companii mari, nu pentru utilizatori mici, cum ar fi programatori individuali sau
grupuri de programatori.
Pentru cei din urmă, protecţia prin posesia unui disc cheie extrem de dificil de copiat se dovedeşte a fi
mult mai eficientă. Primele protecţii de acest tip au apărut pe discuri floppy, unde informaţia era
înregistrată într-un mod imposibil de copiat prin deteriorarea suprafeţei discului cu un obiect ascuţit.
Sectorul defect de pe discul floppy se identifică în aplicaţia originală şi se verifică de fiecare dată la
pornirea acesteia. În zilele de azi acest mecanism este folosit pentru suporturi optice de tip CD/DVD,
discuri compacte, dar deteriorarea se face de cele mai multe ori cu laser. Legarea aplicaţiei de existenţa
unui disc cheie imposibil de copiat era menită să descurajeze mult pirateria programelor.
Alte tipuri de protecţie bazate pe posesia unei componente cheie limitează numărul de execuţii al
programului sau permite folosirea acesteia doar o perioadă de timp limitată. Aceste mecanisme sunt
folosite adesea în aplicaţia care instalează programul, unde cheia este cerută o singură dată, ulterior
programul urmând să funcţioneze independent de existenţa componentei cheie.
Ambele tipuri de protecţie discutate pot să conţină şi alte restricţii pe perioada de încercare a
programului sau în versiunea demonstrativă. Din acestea menţionăm interzicerea accesului la anumite
componente din meniu şi limitarea numărului de instalări ale programului. Restricţiile diferă de la o
aplicaţie la alta, depinzând de alegerea producătorilor. Acelaşi producător poate folosi acelaşi tip de
protecţie pentru produsele sale sau tipuri diferite pentru fiecare produs, caz în care protecţia se dovedeşte
a fi mai eficientă, dar preţul produsului mai ridicat.
Diversificarea mecanismelor de securitate a programelor de calculator a favorizat protecţia cu numere
seriale care e mult mai populară decât protecţia cu componente cheie. Producătorii de programe trebuie să
aleagă sisteme de securitate ale produselor care nu crează inconveniente pentru utilizatorii autorizaţi. În
caz contrar chiar şi aceşti utilizatori vor vizita primul distribuitor ilegal de programe, în ciuda
avertismentelor şi legilor în vigoare.
9

La soluţiile de protecţie explicate la începutul acestui paragraf se adaugă şi cele comerciale. Prin
soluţii de protecţie comerciale se înţelege mulţimea de programe dedicate protecţiei fişierelor executabile.
Multe companii producătoare de programe recurg la aceste soluţii comode care prezintă avantaje şi
dezavantaje şi necesită o documentare riguroasă înainte de a le cumpăra şi folosi. Enumerăm mai jos
câteva din programele de protecţie de fişiere executabile existente azi pe piaţă.
2.6 Concluzii
Din studiului situaţiei actuale în domeniul protecţiei aplicaţiilor de calculator, prezentate în
paragrafele anterioare, rezultă următoarele concluzii:
Orice soluţie de protecţie a unui program de calculator este menită să întârzie cât mai mult apariţia
unui crack valid pentru programul respectiv. Această întârziere conduce la o creştere automată a
timpului de vânzare şi a profiturilor programatorilor.
Protecţia cu un protector existent deja pe piaţă implică riscul existenţei unor metode de cracking a
protectorului utilizat. Din această cauză, înainte de procurarea oricărui program protector trebuie
făcută o documentare riguroasă şi o analiză a programelor existente. Se vor procura programe care
sunt actualizate în permanenţă şi se va evita achiziţionarea celor ale căror proiecte au fost
abandonate.
Fiecare program protector de fişiere executabile oferă aceleaşi opţiuni standard de protecţie ale
unui fişier executabil, şi anume: protecţie anti-dumping, adică împiedică descărcarea din memorie
a codului asamblare complet al fişierului executabil protejat; protecţia tabelei de importuri, care
ascunde numele librăriilor importate şi ale funcţiilor Windows API apelate; protecţie antidebugging,
adică face imposibilă citirea logicii codului asamblare a unui fişier executabil încărcat
într-un debugger sau împiedică încărcarea fişierului executabil protejat în debugger prin
închiderea ferestrei principale a debugger-ului fără o anunţare în prealabil a crackerului.
Implementarea acestor opţiuni depinde de creativitatea şi experienţa programatorilor, făcând
posibilă astfel aducerea de contribuţii noi în domeniu prin optimizarea soluţiilor existente sau
elaborarea unor soluţii originale. Acestor direcţii de cercetare deschise în continuare li se adaugă şi
posibilitatea de inovare a unor opţiuni de protecţie originale, cum ar fi algoritmi de criptare noi,
utilizaţi asupra numerelor seriale la înregistrarea unui program de calculator. Dezavantajul
utilizării aceluiaşi protector asupra mai multor programe constă în aplicarea aceleiaşi scheme de
protecţie mai multor programe, prin urmare compromiterea unuia dintre ele duce la
compromiterea înregii serii de programe protejate.
Dacă nu se doreşte procurarea unui protector comercial se vor implementa scheme de protecţie
originale şi complexe care să efectueze cât mai multe calcule şi cât mai complicate la verificarea
numerelor seriale pentru a întârzia cât mai mult procesul de cracking. Pentru programele protejate
care utilizează internetul se va implementa în mod obligatoriu o rutină de verificare online a
autenticităţii utilizatorului programului. Se vor evita mesajele de eroare şi de succes din fereastra
de înrregistrare, iar validarea numărului serial sau a parolei de înregistrare se va face într-un fişier
separat, eventual de tip .DLL prin apelare dinamică a rutinelor din acest fişier. Acest tip de
protecţie dă rezultate foarte bune. Pe lângă utilizarea unui număr serial pentru înregistrare se
recomandă utilizarea unui fişier cheie a cărui existenţă şi conţinut să fie verificate în permanenţă la
utilizarea programului protejat. În final, se poate proiecta propriul program de protecţie, si acesta
este unul din obiectivele acestei teze, pentru a veni în sprijinul programatorilor. O rutină eficientă
de protecţie trebuie scrisă într-un limbaj de programare de nivel scăzut sau mediu. În cazul
10

utinelor de protecţie scrise în C/C++ se recomandă optimizarea lor prin inserarea de porţiuni de
cod asamblare.
În decursul acestor 3 ani de elaborare a tezei am efectuat un studiu asupra a mai mult de 400 de
programe de calculator din care amintesc jocuri, convertoare audio şi video, diverse utilitare
educaţionale şi programe antivirus. Aceste programe provin de la exact 196 companii de software.
Obiectivele studiului au fost:
1. observarea utilităţii elaborării unui nou program de protecţie şi optimizării celor existente;
2. elaborarea unei statistici a utilizării protectoarelor comerciale existente şi enumerate în
paragraful 2.5 din această teză, vezi tabelul 1.
Rezultatele studiului efectuat relevă că doar 25% din companiile de soft selectate au optat pentru
utilizarea unui protector comercial, şi se observă că ASProtect este în topul preferinţelor acestora urmat de
Molebox şi de Execryptor, ultimul pierzând teren datorită neactualizării programului din 2005. Faptul că
celelalte programe sunt puţin utilizate, sau deloc, cum ar fi Private Exe Protector, care nu a fost întâlnit
deloc în eşantionul examinat, se datorează probabil faptului că intră în conflict cu programele antivirus şi
preţului ridicat în comparaţie cu ceea ce oferă. Ultimele afirmaţii reies din analiza impresiilor
utilizatorilor de protectoare comerciale.
Rămân 147 de firme, adică 75% din totalul analizat, care preferă elaborarea schemei proprii de
protecţie sau chiar dezvoltarea propriului protector. Prin elaborarea propriei scheme de protecţie se
înţelege de cele mai multe ori o simplă comparare de caractere ale unui şir sau operaţii simple cu şiruri de
caractere, nivelul avansat de protecţie lipsind cu desăvârşire.
Număr Protector utilizat
companii
25 ASProtect
11 Molebox
7 Execryptor
3 Enigma Protector
3 Alte protectoare:
ExeWrapper, Themida,
SVKP
147 Nu utilizează protector
comercial
Tabelul 1 –Utilizarea programelor comerciale de protecţie a fişierelor executabile
Obţinerea acestor rezultate au stat la baza elaborării acestei teze, deoarece reiese că se impun soluţii
noi de protecţie a programelor de calculator şi optimizarea celor existente, care să ducă la o fiabilitate
ridicată şi să întârzie cât mai mult procesul de cracking şi să crească timpul de vânzare.
Din motive de securitate, numele companiilor din eşantionul selectat pentru efectuarea testelor nu pot
fi divulgate deoarece acest lucru ar putea crea inconvenienţe programatorilor.
11

3. Fundamente teoretice de bază
3.1 Structura şi parametrii de bază ai unui fişier executabil
Aşa cum am precizat la începutul capitolului 2, la finalizarea procesului de compilare şi legare a unui
program, cu oricare din mediile de programare existente, rezultă un fişier cu extensia .exe, .dll, .ocx, etc.
în funcţie de mediul de programare folosit, [6], [13], [14], numit fişier executabil, în limba engleză
portable executable, prescurtat PE. Aşa cum reiese din studiile efectuate în capitolul 2, în forma sa
imediat după compilare, fişierul executabil este vulnerabil şi se impun metode de protecţie pentru a
ascunde informaţiile legate de structura lui. Pentru o protecţie eficientă şi de nivel avansat se impune
cunoaşterea amanunţită a structurii şi parametrilor care trebuie preluaţi şi modificaţi din fişierul
executabil.
Formatul unui fişier de tip EXE (Portable Executable File, PE) a fost definit din necesitatea obţinerii
unei metode de executare de cod, pentru sistemul de operare Windows. Pe lângă faptul că un fişier
executabil execută un anume cod, el mai înmagazinează o serie de date necesare executării codului
respectiv, cum ar fi: valori constante, variabile, etc structurate în segmente separate, bine definite.
Structura de bază a unui fişier PE este rezumată în tabelul 2.
Header DOS MZ
Trunchi DOS
Header PE
Tabel secţiuni
Secţiunea 1
…
Secţiunea n
Tabelul 2 – Structura unui fişier executabil
Un fişier executabil are cel puţin două secţiuni: una pentru cod şi una pentru date. O aplicaţie
dezvoltată pentru WindowsNT/2000/XP conţine 9 secţiuni predefinite cu numele: .text, .bss, .rdata, .data,
.rsrc, .edata, .idata, .pdata, şi .debug. Unele programe pot să nu conţină toate aceste secţiuni pe când altele
pot să conţină secţiuni adiţionale necesare execuţiei.
Secţiunile cele mai întâlnite într-un program executabil sunt:
a. secţiunea de cod executabil numită .text (Microsoft) sau .CODE (Borland);
b. secţiunea de date numită .data, .rdata, .bss (Microsoft) sau .DATA (Borland);
c. secţiunea de resurse numită .rsrc;
d. secţiunea de date exportate numită .edata;
e. secţiunea de date importate numită .idata;
f. secţiunea .debug
Numele secţiunilor sunt irelevante deoarece sunt ignorate de sistemul de operare şi sunt prezente
numai pentru convenienţa programatorului. Un alt aspect important al fişierelor executabile este că
structura acestora de pe disc se păstrează şi atunci când sunt încărcate în memorie astfel încât dacă este
posibilă localizarea informaţiei în fişier pe disc atunci este posibilă şi când fişierul este copiat în memorie.
De fapt fişierul executabil nu este copiat exact în memorie. Windows decide ce părţi anume se copiază,
celelalte fiind omise. Copierea se face începând cu headerul DOS, de la adrese mici iar părţile omise sunt
plasate la sfârşitul fişierului la adrese mai mari decât părţile deja copiate. De asemenea locaţia unei
12

componente a fişierului în memorie diferă adesea de cea de pe disc datorită organizării memoriei virtuale
Windows în pagini. Când secţiunile sunt încărcate în RAM ele sunt aliniate astfel încât să ocupe pagini de
memorie de 4Kb, fiecare secţiune ocupând o nouă pagină.
Memoria virtuală reprezintă un intermediar între software şi hardware, stabilind astfel un strat
invizibil între cele două componente ale calculatorului şi interzicând accesul direct la componentele
hardware. La fiecare încercare de accesare a memoriei, procesorul consultă un tabel de pagini care spune
procesului executat care memorie fizică sa o folosească. Avantajele memoriei virtuale sunt:
Oferă posibilitatea creării spaţiilor de adrese multiple. Un spaţiu de adresă reprezintă un tabel de
pagini care permite accesul la memoria corespunzătoare procesului curent. Asigură independenţa
proceselor executate astfel încât la întreruperea bruscă a unui anume proces spaţiile de adrese a
mai multor procese să nu se suprapună ducând astfel la o întrerupere bruscă a întregului sistem.
Oferă procesorului posibilitatea de a crea reguli de acces la memorie. Organizarea pe secţiuni a
unui fişier executabil este necesară deoarece părţi diferite ale fişierului sunt tratate diferit de către
managerul de memorie la încărcarea unui anumit modul. În momentul încărcării, managerul de
memorie stabileşte drepturile de acces pe pagini de memorie pentru fiecare secţiune în parte în
funcţie de setările din headerul secţiunii. Acest lucru determină dacă o secţiune dată se poate citi,
scrie sau executa pe o pagină nouă. Dimensiunea implicită a unei pagini pentru Windows este de
4096b (1000h). Pe disc în schimb repartiţia fişierelor executabile pe pagini de 4Kb ar constitui o
risipă de spaţiu. Din această cauză antetul PE conţine două câmpuri de aliniere diferite: aliniere
secţiuni şi aliniere fişier adică “section alignment” şi “file alignment”. Câmpul aliniere secţiuni
stabileşte modul în care sunt încărcate secţiunile şi este explicat mai sus. Câmpul aliniere fişier (de
obicei de 512 bytes sau 200h) reprezintă modul în care secţiunile sunt aliniate în fişier pe disc şi
este un multiplu de dimensiunea fiecărui sector de pe disc pentru a optimiza procesul de încărcare.
Oferă posibilitatea creării unui fişier temporar pe hard-disk, care să conţină pagini de memorie
neutilizate momentan. De exemplu, dacă o aplicaţie a fost executată şi apoi este trecută în mod
“idle” spaţiul ei de memorie este copiat pe hard-disk şi astfel se eliberează spaţiu în memorie
pentru alte aplicaţii executate ulterior. Executarea aplicaţiilor este la discreţia utilizatorului,
sistemul de operare comutând automat între spaţiile de memorie corespunzătoare fiecărei aplicaţii
curente şi copiind pe hard-disk spaţiile aplicaţiilor neutilizate temporar.
Când fişierele executabile sunt încărcate în memorie, versiunea încărcată se numeşte modul. Pointerul
care conţine adresa de start unde începe copierea fişierului se defineşte HMODULE. Un modul din
memorie conţine tot codul, datele şi resursele dintr-un fişier executabil pe când termenul proces se referă
la un spaţiu de memorie dedicat care poate fi folosit la executarea unui astfel de modul.
Antetul DOS, DOS Header, Toate fişierele executabile încep cu un antet DOS care ocupă primii 64
octeţi ai fişierului. În acest caz dacă programul este executat din DOS sistemul de operare îl recunoaşte ca
un program executabil valid şi rulează în continuare trunchiul DOS imediat după header. Trunchiul DOS
afişează de obicei mesajul “This program must be run under Microsoft Windows".
DOS Header este o structură IMAGE_DOS_HEADER definită în fişierele antet windows.inc şi
windows.h care pot fi localizate uşor în subdirectoarele \include\directory ale diverselor medii integrate de
programare de la Microsoft.
Antetul fişierului executabil, PE Header, este termenul general pentru structura definitită
IMAGE_NT_HEADERS. Această structură conţine informaţii esenţiale folosite de Windows la
încărcarea fişierului EXE. Structura are 3 membri şi este definită în fişierul antet windows.inc.
Signature este o constantă de tip DWORD care conţine valoarea 50h 45h 00h 00h, adică iniţialele
“PE” urmate de două zerouri.
13

FileHeader reprezintă următorii 20 de octeţi ai fişierului PE şi conţine informaţii despre structura
fizică a fişierului cum ar fi numărul lui de secţiuni. FileHeader este definit de asemenea în fişierul
windows.inc.
OptionalHeader este prezent în fiecare fişier executabil şi formează următorii 224 de octeţi conţinând
informaţii despre structura logică a fişierului
Din cei 224 de octeţi ai structurii OptionalHeader ultimii 128 sunt ocupaţi de DataDirectory. Membrii
acestei structuri care prezintă un interes aparte pentru această lucrare sunt:
AddressOfEntryPoint care este adresa relativă ( Relative Virtual Address) a primei instrucţiuni
executată la încărcarea fişierului executabil în Windows. De exemplu, dacă se doreşte devierea de la
fluxul execuţiei din start atunci această valoare trebuie schimbată cu una nouă care va fi executată prima
la încărcarea fişierului.
ImageBase reprezintă adresa de bază implicită la care sistemul de operare Windows încarcă în
memorie fişierul executabil. Această adresă este atribuită fişierului executabil la legare. În 99% din
cazuri adresa este 400000h. Windows poate să nu încarce fişierul la adresa respectivă dacă un alt modul
ocupă spaţiul respectiv.
SectionAlignment reprezintă modul de aliniere al secţiunilor în memorie. De exemplu, dacă valoarea
acestui câmp este 4096 (1000h), fiecare secţiune trebuie să înceapă la multipli de 4096 octeţi.Dacă prima
secţiune este la 401000h şi dimensiunea ei este 10 octeţi, următoarea secţiune trebuie să înceapă la
402000h chiar dacă spaţiul de adresă dintre 401000h şi 402000h rămâne în majoritate neutilizat.
FileAlignment reprezintă modul de aliniere al secţiunilor în fişier. De exemplu, dacă valoarea în acest
câmp este 512 (200h), fiecare secţiune trebuie să înceapă la multipli de 512 octeţi. Dacă prima secţiune se
află la offsetul 200h şi are o mărime de 20 de octeţi, următoarea secţiune trebuie să înceapă la offsetul
400h iar spaţiul dintre offseturile 532 şi 1024 rămâne neutilizat.
SizeOfImage reprezintă dimensiunea totală a imaginii fişierului PE în memorie. Este egală cu suma
tuturor antetelor şi secţiunilor aliniate la SectionAlignment.
SizeOfHeaders suma dintre dimensiunea tuturor antetelor şi dimensiunea tabelului de secţiuni. Altfel,
această valoare reprezintă dimensiunea fişierului minus suma tuturor dimensiunilor secţiunilor fişierului.
Se mai poate folosi şi ca offsetul primei secţiuni din fişierul PE.
DataDirectory este un vector de 16 structuri de tipul IMAGE_DATA_DIRECTORY, fiecare
ocupând 8 octeţi şi care conţin locaţiile şi dimensiunile unor date din fişierul executabil, expuse în tabelul
2. Analog tabelului de secţiuni care reprezintă directorul rădăcină al secţiunilor fişierului executabil,
DataDirectory reprezintă directorul rădăcină al celor 16 componente logice înmagazinate fiecare în
secţiunea corespunzătoare.
14

4. Proiectarea şi dezvoltarea unui program de protecţie a
fişierelor executabile
Această teză are ca obiectiv proiectarea şi implementarea unui program destinat protecţiei automate a
fişierelor executabile. Motivele care au dus la dezvoltarea acestui program sunt următoarele:
în urma studiului prezentat în paragraful 2.6 rezultă că aproximativ 75% din companiile de
software nu utilizează mijloace de protecţie pentru a-şi proteja programele produse.
lipsa prezentării unei infrastructuri necesare implementării unui program protector de fişiere
executabile din literatura de specialitate.
Primul pas în implementare este alegerea limbajului de programare. Aşa cum reiese din paragraful
2.6, cea mai bună alegere este un limbaj de programare de nivel scăzut sau mediu. În această teză am
optat pentru dezvoltarea completă a programului protector în limbaj de asamblare. Se poate alege C sau
Delphi datorită posibilităţii de scriere de cod asamblare intercalat cu oricare din aceste două limbaje de
programare.
Un program protector de fişiere executabile are două componente principale:
Componenta packer, care efectuează următoarele operaţii:
1. crează o copie de siguranţă a fişierului executabil protejat;
2. alocă spaţiu de memorie fişierului care se doreşţe să fie protejat;
3. identifică fişierul protejat ca fiind de tip executabil, prin citirea şi verificarea unor valori
înglobate în fişier;
4. elimină tabela de importuri a fişierului protejat;
5. criptează numele fişierelor librărie .DLL şi ale funcţiilor Windows API;
6. criptează secţiunile de cod din fişierul protejat sau numai o parte din acestea utilizând cod
polimorfic;
7. adaugă în final o nouă secţiune fişierului protejat, creând astfel spaţiu pentru injectarea
codul componentei depacker în fişierul protejat;
8. construieşte porpria-i tabelă de importuri.
Componenta depacker sau loader care efectuează următoarele operaţii:
1. efectuează apelul funcţiilor Windows API din componenta depacker;
2. face saltul la punctul de intrare al fişierului executabil protejat;
3. iniţializează şi reconstruieşte noua tabelă de importuri a fişierului executabil protejat, după
eliminarea celei originale din componenta packer;
4. criptează propriul cod şi conţine motorul metamorfic al programului protector, responsabil
de toate artificiile efectuate asupra codului protejat. Ca metode de protecţie se utilizează
obfuscarea statică şi dinamică.
Programul protector trebuie să satisfacă următoarele condiţii:
să nu intre în conflict cu niciunul din sistemele de operare Windows existente şi să ruleze pe
oricare din acestea;
să nu intre în conflict cu niciunul din programele antivirus. Intrarea în conflict cu oricare din
acestea duce la avertizarea utilizatorilor şi evident la diminuarea încrederii în programul
protector.
Ca mediu integrat de dezvoltare am ales Winasm Studio deoarece este distribuit gratuit pe internet la
http://www.winasm.net, suportă sintaxa MASM32 şi oferă toate facilităţile unui mediu integrat de
dezvoltare de nivel avansat.
15

Convenim ca toate variabilele declarate şi utilizate în program să fie editate începând cu literă mică şi
apoi toate cuvintele din care se compun se vor distinge prin majuscula cu care încep. Fiecare variabilă
declarată şi utilizată în program va avea nume cât mai sugestiv şi va fi explicată la finalul anexei 3.
De asemenea convenim ca toate etichetele utilizate în program să fie redactate cu cuvinte începând cu
majuscule separate de caracterul “underline”.
În paragrafele care urmează sunt prezentate şi analizate în detaliu fiecare din operaţiile efectuate de
componentele packer şi depacker.
Codul sursă al programului protector dezvoltat în această teză este conţinut în întregime în anexa 3.
4.3 Concluzii
În urma implementării şi utilizării programului de protecţie a fişierelor executabile dezvoltat în
această teză rezultă următoarele concluzii:
Datorită alegerii limbajului de asamblare pentru scrierea codului sursă, programul are o viteză
mare de execuţie şi permite efectuarea de operaţii imposibile unor limbaje de nivel înalt. Aceste
operaţii sunt: efectuarea transformărilor la nivel de limbaj de asamblare, numite transformări
metamorfice, scrierea de cod care se automodifică la execuţie numit cod polimorfic, inserarea de
segmente de cod pentru obfuscarea codului asamblare generat de compilatoare şi parcurgerea
opcode instrucţiune în limbaj de asamblare. În urma testelor efectuate în Visual C++, Visual Basic
şi Delphi, obfuscarea codului implementat este redusă datorită optimizării codului de către
compilatoarele mediilor de programare. Utilizarea buclelor prezentate în paragraful 4.2.6 a fost
imposibilă în oricare din mediile de programare enumerate.
Programul protector rulează sub orice sistem de operare Windows: 98, XP, Vista, Windows 7.
Programul protector nu intră în conflict cu următoarele programe antivirus: Norton Antivirus,
Norton Internet Security, AVG, Nod32.
Din metodele alese pentru implementare reiese maleabilitatea programului de protecţie. Codul
sursă prezentat în anexa 3 oferă o soluţie de implementare care stă la dispoziţia programatorilor
individuali, sau echipelor de programatori fie pentru a-şi proteja programele în forma în care este
prezentată, fie pentru a schimba codul sursă.
Programul de protecţie a fost testat pe toate cele aproximativ 400 de programe care au constituit
obiectul studiului din paragraful 2.6, funcţionând fără nicio problemă. Rezultă că poate fi utilizat
pentru a proteja orice fişiere executabile rezultate în urma compilării cu oricare din mediile de
programare de la Microsoft sau Borland.
În urma compararării programului de protecţie dezvoltat în aceată teză cu programele de protecţie
enumerate în paragraful 2.5 rezultă datele din tabelul 7.
În tabelul 7 am folosit abrevierile: Err = mesaj de eroare cauzat de insuficienţa spaţiului în fişierul
executabil protejat pentru adăugarea noii secţiuni, OK = funcţionează corect, PE = fişer de tip executabil.
Se observă că dacă tabela de importuri a fişierului protejat conţine 2 sau mai puţine importuri,
programul nostru dă mesaj de eroare, fiind în imposibilitatea de a adăuga propria secţiune care conţine
componenta depacker. Acest lucru nu constituie un impediment deoarece nu se vor întâlni programe
executabile cu 2 sau mai puţine importuri, excepţie făcând viruşii. S-a realizat totuşi o optimizare faţă de
ASProtect şi ExeWrapper, care dau aceste mesaje la o tabelă cu 1, 2, 3, 4, 5, şi 6 importuri.
16

Nr. Denumire
program
protector
Număr importuri
1 2 3 4 5 6 7
17
VC++ 6 VBasic
1 Program teză Err Err OK OK OK
2 Execryptor Conflict cu Norton Antivirus Invalid PE OK
3 AS Protect Nu Nu Err Err Err Err OK OK OK
4 AS Protect SKE Nu Nu Err Err Err Err OK OK OK
5 Enigma Conflict cu Norton Antivirus
6 Exe Wrapper Err Err Err Err Err Err OK OK OK
7 Molebox OK OK OK
8 SVKP Conflict cu Norton Antivirus
9 Themida Conflict cu Norton Antivirus
10 Private Exe
Protector
OK OK OK
Tabelul 7 – Compararea programului protector cu programe existente
Ca soluţii fiabile în urma acestei comparaţii rămân Molebox, Private exe Protector şi programul
nostru.
5. Algoritmi de criptare a numerelor seriale
5.6 Rezultate obţinute în urma criptării cu o singură matrice cheie
Considerăm fixate aceleaşi elemente din paragraful 3, exemplul 2, şi criptăm numărul serial
UTCN*PROTECTOR folosind o singură matrice de criptare, împreună cu transformările din paragraful 4
asupra elementelor matricei de stare
T =
3ˆ 9ˆ 0
1
ˆ 2
3ˆ 1
2ˆ 2
5ˆ 1
7ˆ 1
4ˆ 1
9ˆ 1
9
ˆ
3
1
ˆ
5ˆ a
= a
a
Aplicăm prima transformare cu formula ai’ = a(i+k)mod(mn) în care punem 1{0,1, ..., 11}, k=4, şi
obţinem elementele noii matrice de stare:
care devine reactualizată
0
1
2
a
a
a
3
4
5
a
a
a
6
7
8
a
a
a
9
10
11
a0’ = a4; a1’=a5; a2’=a6; a3’=a7; a4’=a8; ...; a8’=a0; a9’=a1; a10’=a2; a11’=a3
a
0 '
T’ = a
1'
a
2 '
a3
'
a4
'
a5
'
a6
'
a7
'
a8
'
a9
' a
a10
'=
a
a '
11 a
Aplicăm a doua transformare cu formula:
4
5
6
a
a
a
7
8
9
a
a
a
10
11
0
a 1
a2
=
a
3
7ˆ 5
1
ˆ
2
1
ˆ 2
5ˆ 9ˆ 4
1
ˆ 1
0ˆ 9
2
ˆ
3
1
ˆ
3
ˆ
3
1
ˆ
9ˆ 1

fiecărui element din noua stare a matricei T’:
şi noua matrice de stare este
ai’ = ai ai+1 ai+2 ai+3 ai+4 ai+5
a0’ = a0 a1 a2 a3 a4 a5=0ˆ ; a1’ = a1 a2 a3 a4 a5 a6= 4ˆ a2’ = a2 a3 a4 a5 a6 a7=8ˆ ; a3’ = a3 a4 a5 a6 a7 a8= 1ˆ 1
a4’ = a4 a5 a6 a7 a8 a9= 6ˆ 1 ; a5’ = a5 a6 a7 a8 a9 a10=0ˆ a6’ = a6 a7 a8 a9 a10 a11=8ˆ ; a7’ = a7 a8 a9 a10 a11 a0= 4ˆ a8’ = a8 a9 a10 a11 a0 a1= 0ˆ ; a9’ = a9 a10 a11 a0 a1 a2= 0ˆ 2
a10’ = a10 a11 a0 a1 a2 a3= 5ˆ 1 ; a11’ = a11 a0 a1 a2 a3 a4=8ˆ
T” =
8ˆ 4ˆ 0ˆ 0ˆ 6ˆ 1
1
ˆ 1
18
0 ˆ
8 ˆ
4 ˆ
8
ˆ
5ˆ 0
1
ˆ 2
Deplasăm ciclic liniile noii matrice de stare conform celei de-a treia transformări şi obţinem a treia
stare a matricei:
Utilizăm matricea cheie
T’’’ =
4ˆ 6ˆ 0
1
ˆ
P =
2ˆ 1ˆ 1ˆ 8ˆ 1ˆ 1
8 ˆ
2 ˆ
1 ˆ
1 ˆ
8ˆ 5ˆ 0
1
ˆ
1
ˆ
2ˆ 0ˆ ,
0
ˆ
4ˆ 0ˆ 2
aceeaşi ca şi în exemplul 2 din paragraful 3, iar Q=I2. Efectuăm înmulţirea matricelor
PT’’’ =
2ˆ 1ˆ 1ˆ 2 ˆ
1 ˆ
1 ˆ
1
ˆ
2ˆ 0ˆ
4ˆ 6ˆ 0
1
ˆ
8ˆ 1ˆ 1
8 ˆ
8ˆ 5ˆ 0
1
ˆ
0
ˆ
4ˆ 0ˆ 2
=
0ˆ 1
2
ˆ
9ˆ 5ˆ 2
1
ˆ
4
1
ˆ
7 ˆ
8 ˆ
0 ˆ
9
ˆ
1
1
ˆ
5ˆ =Tc
iar rezultatul obţinut dă criptarea numărului serial: JAUDLOGHXEAS.
Decriptarea acestui cuvânt se efectuează aplicânt inversele fiecărei transformări efectuate, şi
anume:

P -1
Tc =
9
ˆ 9ˆ 9 1 ˆ
8ˆ 4 1 ˆ 9 1 ˆ
0
1
ˆ 8 1 ˆ 9 1 ˆ
9
ˆ 0 1 ˆ 5ˆ 0 1 ˆ
1
2
ˆ 8ˆ 2ˆ 1 1 ˆ
5ˆ 7ˆ 4ˆ 9ˆ
=
0
ˆ 8ˆ 8ˆ 4ˆ 4ˆ 5ˆ 8 1 ˆ 6ˆ 0
1
ˆ 0 2 ˆ 1ˆ 0 1 ˆ
=T’’’
apoi liniile matricei T’’’ se deplasează ciclic spre dreapta în ordinea următoare: prima linie nu se
deplasează, a doua linie se deplasează la dreapta cu o poziţie şi a treia linie se deplasează la dreapta cu 2
poziţii, rezultând matricea T’’. Asupra elementelor acestei matrice se aplică formulele:
care determină matricea
a0 = a0’-( a1 a2 a3 a4 a5)= 2ˆ 2 ; a1 = a1’-( a2 a3 a4 a5 a6)= 5ˆ 1
a2 = a2’-( a3 a4 a5 a6 a7)= 7ˆ 1 ; a3 = a3’-( a4 a5 a6 a7 a8)= 4ˆ 1
a4 = a4’-( a5 a6 a7 a8 a9)= 9ˆ 1 ; a5 = a5’-( a6 a7 a8 a9 a10)=5ˆ a6 = a6’-( a7 a8 a9 a10 a11)=3ˆ ; a7 = a7’-( a8 a9 a10 a11 a0)= 9ˆ 1
a8 = a8’-( a9 a10 a11 a0 a1)= 0ˆ 2 ; a9 = a9’-( a10 a11 a0 a1 a2)= 9ˆ 1
a10 = a10’-( a11 a0 a1 a2 a3)=3ˆ ; a11 = a11’-( a0 a1 a2 a3 a4)= 3ˆ 1 .
T’ =
7ˆ 5
1
ˆ
2
1
ˆ 2
5ˆ 9ˆ 4
1
ˆ 1
Asupra fiecărui element din T’ se efectuează substituţiile:
şi rezultă prima matrice de stare
19
0ˆ 9
2
ˆ
3
1
ˆ
3
ˆ
3
1
ˆ
9ˆ 1
.
a0 = a4’; a1=a5’; a2=a6’; a3=a7’; a4=a8’; ...; a8=a0’; a9=a1’; a10=a2’; a11=a3’
T =
3ˆ 9ˆ 0
1
ˆ 2
3ˆ 1
2ˆ 2
5ˆ 1
7ˆ 1
4ˆ 1
9ˆ 1
9
ˆ
3
1
ˆ
5ˆ corespunzătoare numărului serial UTCN*PROTECT.
Transformările neliniare efectuate asupra numărului serial înaintea aplicării cheilor de criptare
scad considerabil vulnerabilitatea acestui cifru. O posibilă îmbunătăţire care reiese din aplicaţiile practice
asupra mai multor numere seriale este generalizarea celei de-a doua transformări neliniare astfel încât să
nu depindă numai de elementele matricei de stare ci se vor insera în formulă termeni care sunt elemente
ale unei matrice linie numită matrice sau vector de difuzie.
Considerăm următoarea matrice linie, notată cu D, cu mn elemente, unde m şi n sunt numărul de
linii respectiv de coloane ale matricei de stare T:
d d d
D ...
şi modificăm formula (10), prin adunarea unui element de pe poziţia i, din D, la sfârşitul sumei:
1
2
mn

a’i = ai a(i+k)mod(mn) a(i+k+1)mod(mn) a(i+k+2)mod(mn) ...a(i+k+l)mod(mn)di (12)
unde pentru decriptare, avem
ai = ai’ – (a(i+k)mod(mn) a(i+k+1)mod(mn) a(i+k+2)mod(mn) ...a(i+k+l)mod(mn)di). (13)
O altă variantă care se poate utiliza la aplicarea cheilor prin produs de matrice este interpretarea
coloanelor matricei de stare ca polinoame de gradul l şi înmulţirea cu un polinom cu coeficienţi aleşi
astfel încât să formeze o matrice inversabilă.
5.7 Utilitatea algoritmilor de criptare cu matrice
Prezentăm în continuare punerea în practică a algoritmilor elaboraţi în paragrafele anterioare la
protecţia cu număr serial a unui program de calculator.
Programul de protecţie prezentat în capitolul 4 protejează automat fişierul executabil, la alegerea
utilizatorului, cu un număr serial cu 25 de caractere, de forma :
C1C2C3C4-C6C7C8C9C10C11C12C13C14-C15C16C17C18C19C20C21C22C23C24C25
unde primul bloc de 4 caractere este verificat cu o matrice cheie pătratică de ordinul 2, al doilea bloc de 9
caractere este verificat cu o matrice cheie pătratică de ordinul 3 şi al treilea bloc de 12 caractere este
verificat cu 2 matrice cheie pătratice de ordinul 4. Acest lucru este realizat prin operaţiile:
Se codifică prin program toate caracterele numărului serial cu un tablou de numere întregi;
După codificare, se împarte textul introdus de utilizator în blocuri de 4, 9, respectiv 12 caractere;
Se procesează primul bloc de 4 caractere cu transformările T1 – T4 şi se criptează conform
algoritmului cu o singură cheie cu 4 caractere;
Se procesează al doilea bloc de 9 caractere cu transformările T1 – T4 şi se criptează conform
algoritmului cu o singură cheie cu 9 caractere;
Se procesează ultimul bloc de 12 caractere şi se criptează cu două chei, fiecare de câte 16
caractere.
Am implementat aceste operaţii în limbajul C, într-un fişier librărie separat, care este încărcat dinamic
în memorie la verificarea numerelor seriale introduse pentru înregistrarea programelor protejate.
Complexitatea operaţiilor efectuate asupra caracterelor numerelor seriale duce la creşterea de linii de cod
în limbaj de asamblare generate de compilatorul C.
În afara operaţiilor utilizate asupra caracterelor numerelor seriale se mai pot efectua şi operaţii de
verificare aritmetice sau logice, pentru a creşte timpul de debugging.
Am inserat porţiuni de cod în limbaj de asamblare pentru criptarea liniilor de cod care efectuează
operaţiile asupra caracterelor numerelor seriale.
În final rezultă o schemă de protecţie eficientă, şi uşor de actualizat datorită implementării într-un
fişier librărie separat.
Modificări posibile care se pot efectua asupra schemei de protecţie cu număr serial:
Creşterea sau scăderea numărului de caractere; evident o creştere duce la o securitate sporită şi
creştere a fiabilităţii.
Creşterea numărului de blocuri în care este separat şirul de caractere introdus la înregistrare;
Aplicarea algoritmilor cu două chei de criptare fiecărui bloc din numărul serial;
Utilizarea transformărilor neliniare T1 – T4 asupra fiecărei matrice de stare corespunzătoare
fiecărui bloc din numărul serial;
După implementarea algoritmului de protecţie cu număr serial se va face un debugging riguros al
acestuia, urmărind atent conţinutul registrelor procesorului. Se va evita utilizarea funcţiilor standard de
lucru cu şiruri de caractere şi se vor implementa propriile funcţii în fişierul librărie al întregii scheme de
20

protecţie. Se va evita compararea a două şiruri de caractere, compararea efectuându-se asupra fiecărui
caracter din serialul criptat cu rezultatul dorit. Porţiunile de cod care efectuează compararea se vor cripta
cu metoda XOR şi nu se vor afişa mesaje de succes sau de eroare în urma validării numărului serial.
În cadrul rutinei de verificare a numerelor seriale, în acelaşi fişier librărie, se vor implementa
următoarele metode antidebugging:
Ştergerea punctelor de întrerupere software din memorie prin căutarea şi ştergerea instrucţiunii Int
3H cu codul CCh.
Detectarea punctelor de întrerupere hardware din memorie şi oprirea execuţei programului.
Detectarea debuggerului OllyDebugger din memorie şi oprirea execuţiei programului.
6. Evaluarea performanţelor fişierelor executabile protejate cu
programul prezentat în această teză
Vom analiza rezultatele obţinute cu aplicaţia de protecţie a fişierelor executabile dezvoltată în această
teză în funcţie de fiabilitatea, performanţa şi securitatea fişierelor protejate. Programul s-a testat asupra
mai multor programe ţintă dezvoltate în medii de programare diferite, Microsoft Visual Studio (C++,
Basic), Borland C++ şi Delphi. S-au obţinut rezultate foarte bune şi asupra fişierelor executabile generate
de mediul Winasm Studio, scrise în limbaj de asamblare, compilate cu MASM32.
Din punct de vedere al fiabilităţii, rezultă că:
Fişierul protejat nu intră în conflict cu niciunul din sistemele de operare Windows enumerate în
paragraful 4.2.7..
Fişierul protejat nu intră în conflict cu niciunul din programele antivirus enumerate în paragraful
4.2.7.
Dimensiunea în octeţi a programului protejat creşte datorită injectării codului componentei
depacker, dar aceasta nu contravine deloc funcţionării normale a acestuia în condiţiile menţionate
mai sus. În funcţie de vectorul de transformări metamorfice şi compilatorul utilizat procentajul de
creştere a fişierului protejat este prezentat în tabelul 8 de mai jos. Se va avea în vedere valoarea de
prag în octeţi a secţiunii adăugate fişierului executabil, parte a componentei depacker pentru a nu
încetini executarea fişierului protejat. Pentru o bună funcţionare şi un nivel de securitate optim am
obţinut dimensiunea maximă a bufferului de criptare de 5Ko = 5120 octeţi. Se pot utiliza buffere
de criptare/decriptare de dimensiuni mai mici declarate în diferite zone ale componentei depacker.
În continuare măsurăm întârzierea execuţiei programelor protejate cu programul dezvoltat în
cadrul acestei teze. Aceste măsurători determină intervalul optim în care trebuie să se situeze
dimensiunea bufferului de criptare şi timpii necesari procesării acestuia.
6.1 Teste de performanţă
În testele efectuate am ales 10 fişiere executabile, de dimensiuni diferite, ale celor 400 de programe
care au făcut obiectul studiului din paragraful 2.6, ale unor aplicaţii de interes larg, cum ar fi convertoare
audio sau video, convertoare şi editoare de imagini, convertoare şi editoare de fişiere de diferite tipuri, etc.
Dimensiunile fişierelor selectate sunt în intervalul 3ko – 2,1Mo. Am efectuat aceste teste şi datorită
utilităţii lor la protecţia fişierelor executabile cu ajutorul programului de protecţie automată dezvoltat în
cadrul acestei teze.
21

Primul test compară dimensiunea fişierului protejat înainte de protecţie cu dimensiunea fişierului după
protecţie. Se utilizează un buffer de criptare de 1Ko = 1024 octeţi. Rezultatele sunt trecute în tabelul 8,
unde se observă procentul cu care creşte dimensiunea fişierului protejat. Programul protector nu
împachetează resursele fişierului protejat. Din tabel se observă că procentul de creştere a dimensiunii
fişierului protejat scade odată cu creşterea în dimensiune a acestuia. Pentru facilitarea completării
tabelului am folosit notaţia E pentru fişier executabil, astfel notaţia En înseamnă al n-lea fişier executabil
testat.
Fisier EXE E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Dimensiune înainte
de protecţie (ko)
3 40 243 433 644 700 848 1130 1333 2115
Procent de creştere
(%)
1100 80 15 6 4 3 3 2 2 1
Tabelul 8 – Rezultatele primului test de performanţă
Al doilea test compară performanţa executării fişierului protejat înainte şi după protecţie prin
compararea timpilor de încărcare în ambele cazuri. Deoarece fişierul protejat conţine codul componentei
depacker, se creşte timpul necesar încărcării acestuia cu timpul necesar executării operaţiilor de decriptare
şi redirecţionare a tabelei de importuri. Această diferenţă de timp o vom numi întârziere de decriptare.
Testul de măsurare a întârzierii de decriptare constă în protejarea fiecărui fişier executabil selectat şi
măsurarea timpului de încărcare consumat de componenta depacker. În tabelul 9 este prezentată
întârzierea de decriptare a fiecăruia din cele 10 fişiere executabile testate. Menţionăm că nu există o
întârziere de decriptare fixă pentru fiecare fişier executabil datorită dependenţei acestuia de resursele
sistemului de operare, cum ar fi fişiere librărie .DLL şi registrele sistemului Windows. Întârzierea de
decriptare depinde de complexitatea fiecărui program protejat. Prin urmare pentru fişiere executabile
diferite se vor obţine rezultate diferite.
Fisier EXE E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Timp încărcare
înainte de protecţie
(milisecunde)
100 102 180 240 260 265 272 305 320 540
Timp încărcare după
protecţie (ms)
101 103 195 270 295 302 320 350 375 610
Întârziere de
decriptare (ms)
1 1 15 30 35 37 38 45 55 70
Tabelul 9 – Întârzierea de decriptare a fişierelor executabile protejate cu un singur buffer de
criptare de 1024 octeţi
Fisier EXE E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Timp încărcare
înainte de protecţie
(milisecunde)
100 102 180 240 260 265 272 305 320 540
Timp încărcare după
protecţie (ms)
150 183 280 370 400 410 430 470 500 1500
Întârziere de
decriptare (ms)
50 81 100 130 140 145 153 165 180 960
22

Tabelul 10 – Întârzierea de decriptare a fişierelor executabile protejate cu un buffer de criptare 2048
octeţi
Fisier EXE E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Timp încărcare
înainte de protecţie
(milisecunde)
100 102 180 240 260 265 272 305 320 540
Timp încărcare după
protecţie (ms)
250 280 380 470 500 540 552 600 650 1550
Întârziere de
decriptare (ms)
100 178 200 230 240 275 280 255 330 1010
Tabelul 11 – Întârzierea de decriptare a fişierelor executabile protejate cu un buffer de criptare 3072
octeţi
Fisier EXE E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Timp încărcare
înainte de protecţie
(milisecunde)
100 102 180 240 260 265 272 305 320 540
Timp încărcare după
protecţie (ms)
400 475 580 670 700 750 800 870 900 1800
Întârziere de
decriptare (ms)
300 373 400 430 440 485 528 565 580 1260
Tabelul 12 – Întârzierea de decriptare a fişierelor executabile protejate cu un buffer de criptare 4096
octeţi
Din testele efectuate reiese o întârziere medie de decriptare de aproximativ 38 milisecunde pentru un
buffer de criptare de 1Ko, 210 milisecunde pentru 2Ko, 310 milisecunde pentru 3Ko şi 536 pentru 4Ko.
Întârzierea de decriptare este redusă pentru fişiere executabile cu dimensiuni mai mici datorită
dimensiunii mici a secţiunii de cod. Tabelele 9-12 se vor utiliza la setarea dimensiunii bufferelor de
criptare utilizate la protecţie şi la utilizarea multiplă a acestora asupra aceluiaşi program. Întârzierile de
decriptare date în tabele se vor însuma la fiecare utilizare a bufferului de criptare, de dimensiunea
respectivă. Nu se vor admite întârzieri de decriptare mai mari de 2-3 secunde pentru executarea
componentei depacker. Bufferele de criptare pot avea orice dimensiuni intermediare cuprinse în intervalul
[124-5120] octeţi. La utilizarea de buffere de criptare de dimensiuni mai mari creşte considerabil timpul
de compilare al programului protector până la blocarea sistemului de operare
.
6.2 Test de securitate al metodelor de obfuscare
Al doilea test efectuat asupra fişierelor executabile protejate constă în analiza motorului metamorfic al
programului protector, responsabil de obfuscarea dinamică a componentei depacker. Am considerat
primul vector de transformări cu dimensiunea 14. Am măsurat numărul instrucţiunilor generate de
motorul metamorfic în funcţie de numărul de octeţi indicat de variabila DIMENSIUNE_BUFFER,
declarată în paragraful 4.2.6. Rezultatele apar în graficul din figura 12. Testele s-au efectuat pentru
dimensiuni ale bufferului de criptare de cod între 30h=48 octeţi şi 7Ch=124 octeţi. Valoarea minimă s-a
ales convenabil pentru a asigura un nivel de protecţie bun al fişierului ţintă. Pentru un buffer de criptare
corespunzător unui vector de transformări metamorfice, dedimensiune mai mare sau egală cu egal cu
23

7Dh=125, octeţi, se obţin erori de salt datorită faptului că instrucţiunile de salt implementate sunt salturi
scurte (JMP NEAR) sau LOOP, iar creşterea numărului de octeţi impune necesitatea implementării de
salturi de tip JMP.
Num ar instructiuni
80
70
60
50
40
30
20
10
0
N r. instructiuni in functie de nr. octeti
0 20 40 60 80 100 120 140
Num a r octe ti
Figura 12 – Variaţia numărului de instrucţiuni în funcţie de numărul de octeţi
din DIMENSIUNE_BUFFER
De exemplu, salturile scurte implementate la o dimensiune a buffer-ului de criptare de 125, 126, 127,
128 de octeţi nu pot fi luate cu o diferenţă de 1, 2, 3, respectiv 4 octeţi şi numărul de octeţi din diferenţa
de salt creşte cu o unitate. Ca program debugger utilizat pentru teste am folosit Olly Debugger.
Din figura 12 se observă că distribuţia instrucţiunilor în limbaj de asamblare poate fi aproximată
foarte bine de o familie de funcţii liniare. Selectând coordonatele primului punct din grafic (48, 28) şi ale
ultimului punct (124, 70) graficul poate fi aproximat de dreapta de ecuaţie
12 28
y x
(6.2.1)
19
19
Am măsurat frecvenţa de apariţie a fiecărei transformări din tabelele de seturi de instrucţiuni şi
reprezentarea grafică a acestor frecvenţe pentru diferite valori ale variabilei DIMENSIUNE_BUFFER.
Prezentăm frecvenţele de apariţie ale transformărilor din primul tabel pentru valorile
DIMENSIUNE_BUFFER {48, 96, 124} (octeţi) ilustrând în acelaşi timp aceste transformări din cadrul
funcţiei rutinaGenerarePoliMeta aşa cum apar ele la încărcarea în programul debugger Olly Debugger.
Este important de menţionat faptul că am utilizat versiunea 2.0 a lui OllyDebugger. Pentru alte versiuni
ale lui OllyDebugger sau pentru alte programe debugger se obţin rezultate diferite. Pentru frecvenţele de
apariţie ale seturilor de instrucţiuni din tabel folosim notaţiile Ti, i{1, 2, …, 14} iar pentru numărul de
octeţi din DIMENSIUNE_BUFFER nb, unde n{48, 96, 124}.
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14
48b 0 3 1 7 1 1 2 0 0 2 2 5 2 2
96b 3 3 2 8 5 0 0 5 3 2 2 10 4 4
124b 6 3 2 7 4 4 3 4 3 4 4 11 7 8
Tabelul 13 – Frecvenţele de apariţie ale instrucţiunilor inserate aleator
24

Din tabelul de frecvenţe,cu numărul 10 , rezultă că transformările T4 şi T12 apar cel mai des pe când
transformările T6, T7, T8 şi T9 au cele mai mici frecvenţe de apariţie. Frecvenţa de apariţie a fiecărui set de
instrucţiuni depinde de tabelul cu aceste instrucţiuni şi de implementarea funcţiilor de inserare aleatoare.
Utilizarea unei metode de obfuscare dinamică creşte nivelul de securitate al fişierelor executabile
protejate şi face imposibilă urmărirea logică a programului cu un debugger, implicit face imposibilă
atingerea punctului de intrare în programul executabil. Dacă se ajunge la punctul de intrare în program, şi
se descarcă fişierul executabil din memorie pe hard-disk, redirecţionarea tabelei de importuri împiedică
funcţionarea acestuia.
Rezultatele obţinute în urma acestui studiu de performanţă se vor utiliza la determinarea caracterului
dinamic al instrucţiunilor inserate în bufferul de criptare în etapa de testare a acestuia în debugger.
Dinamica execuţiei instrucţiunilor inserate de motorul poli/metamorfic este asigurată de instrucţiunile de
salt din vectorul de transformări. Dacă instrucţiunile de salt din vectorul de transformări lipsesc atunci
rezultă un cod asamblare executat repetat într-o buclă de inducţie mare şi uşor de depaşit după
identificarea ultimelor instrucţiuni inserate. Am testat protecţia cu şi fără instrucţiuni de salt, diferenţele
de nivel de securitate fiind enorme, mai ales la selectarea opţiunii de colorare a instrucţiunilor de salt cu
Olly Debugger. De asemenea, rezultatele obţinute se vor utiliza la elaborarea instrucţiunilor componente
ale vectorilor de transformări unde în mod obligatoriu se vor utiliza instrucţiuni de forma PUSH imm,
unde imm este un operand inserat aleator în scopul modificării stivei procesorului. Nivelul de securitate
creşte la implementarea instrucţiunilor care admit ca operanzi atât registre pe 8 cât şi pe 16 octeţi
distrugând complet liniaritatea codului inserat şi logica codului protejat.
Urmând rezutatele din tabelul 10 şi ecuaţia (6.2.1) se pot elabora modele de apariţie a instrucţiunilor
implementate în vectorii de transformare de diverse dimensiuni, din intervalul [14-44] seturi de
instrucţiuni pe 1, 2, sau 3 octeţi.
6.3 Performanţele implementării algoritmilor de criptare cu matrice
Aşa cum am constatat la finalul paragrafului 5.4 o criptanaliză prin forţă brută a algoritmilor de
criptare elaboraţi se exclude datorită numărului mare de chei de criptare. Analiza frecvenţei de apariţie a
fiecărui caracter în textul criptat nu ajută deloc la spargerea cifrului datorită alegerii aleatoare a alfabetului
şi eventual a lungimii mari a unor numere seriale care pot fi reţinute în interiorul unor fişiere de date.
Vulnerablitatea algoritmilor de criptare elaboraţi în capitolul 5 constă în liniaritatea algoritmului de
criptare cu două matrice. Pentru spargerea cifrului este suficient să se cunoască o bucată din textul iniţial
al numărului serial şi una din numărul serial criptat, apoi prin rezolvarea unui sistem de ecuatii liniare se
poate determina cheia de criptare.
Problema liniarităţii am rezolvat-o utilizând transformările neliniare asupra liniilor si coloanelor
matricei de stare, astfel încât chiar dacă se determină porţiuni de text iniţial şi criptat, o simplă rezolvare a
unui sistem de ecuaţii nu ajută la găsirea cheii de criptare. Aceste transformări se pot aplica şi matricei de
stare criptate cu două matrice de criptare.
Algoritmii de criptare ai numerelor seriale au fost implementaţi în limbaj C. Deşi rezistenţi din punct
de vedere criptanalitic, pot să apară vulnerabilităţi la implementarea acestora. Am testat algoritmul de
criptare cu două matrice cheie şi algoritmul cu o singură matrice cheie dar cu transformări neliniare
efectuate asupra matricei de stare. Am făcut testul asupra codului asamblare generat de compilator fără să
utilizez programul de protecţie automată şi motorul metamorfic al acestuia, analizând efectiv codul
corespunzător operaţiilor efectuate asupra numerelor seriale. Ca instrument de lucru am folosit
OllyDebugger.
25

Pentru fiecare algoritm am urmărit numărul de instrucţiuni de salt şi de test, precum şi conţinutul
registrelor procesorului. Urmând instrucţiunile din ultimul paragraf al secţiunii 5.7, în urma unui
debugging riguros, am obţinut următoarele rezultate:
Nu este posibilă setarea de puncte de întrerupere pe mesaje de eroare sau de succes, acestea
nefiind utilizate;
Nu este posibilă determinarea codului corespunzător verificării numărului serial prin setarea de
puncte de întrerupere pe operaţii cu şiruri de caractere sau afişare de mesaje, evitând utilizarea
funcţiilor puse la dispoziţie de librăriile mediilor de programare şi implementând propriile funcţii;
Porţiunea de cod corespunzătoare rutinei de verificare a numărului serial nu se poate găsi deoarece
este implementată într-un fişier librărie separat şi porţiuni din acesta sunt încărcate dinamic în
memorie, în timpul executării rutinei. Fişierul DLL nu este legat static de fişierul executabil.
În eventualitatea determinării unei porţiuni de cod a rutinei de verificare a numărului serial,
urmărirea logicii acesteia este îngreunată de eliberarea zonei de memorie în care a fost încărcată
imediat după executare şi executarea unei alte porţiuni.
În registrele procesorului nu se afişează întreg numărul serial deoarece rutinele care efectuează
operaţii asupra lui se adresează fiecărui bloc sau caracter în parte din acesta.
7. Concluzii
7.1 Concluzii finale
Activitatea de cercetare care a condus la elaborarea acestei teze s-a orientat spre studiul şi optimizarea
unora dintre cele mai utilizate metode actuale de protecţie a programelor de calculator. Am continuat cu
dezvoltarea unor metode originale de protecţie a programelor de calculator şi punerea la dispoziţie a unei
infrastructuri de dezvoltare a unui program de protecţie automată a fişierelor executabile.
Am ales un eşantion de 400 de programe de calculator comercializate azi pe piaţă prin intermediul
unor websituri şi am analizat fişierul executabil al fiecărui program cu un debugger în scopul determinării
metodelor de securitate şi al fiabilităţii. În urma analizei s-au obţinut rezultatele din paragraful 2.6 la care
mai adăugăm următoarele concluzii referitor la vulnerabilitatea programelor examinate:
Lipsa unei protecţii anti-debugging, care permite analiza fişierului executabil şi compromiterea
acestuia în timp foarte scurt.
Firmele de software utilizează acelaşi sistem de protecţie pentru fiecare program produs. Acest
lucru se poate evita foarte uşor prin măsuri de protecţie diferite pentru fiecare program în parte.
Fiecare schemă de protecţie, cu număr serial sau nu, trebuie supusă unui test cu un program
debugger.
Pentru protecţia programelor se poate opta pentru o simplă schemă cu număr serial sau pentru
implementarea propriilor metode anti-debugging. În primul caz cele mai bune rezultate s-au
obţinut cu scheme cu număr serial care utilizează o verificare cu un fişier cheie criptat, o
verificare online, mai ales pentru aplicaţiile care necesită o conexiune deschisă permanent pentru
funcţionare, sau o verificare a numărului serial implementată separat într-un fişier librărie .DLL
cu rutine de verificare încărcate dinamic în memorie. Este foarte important să se evite încărcarea
în memorie a întregului fişier librărie .DLL care conţine schema de protecţie. În al doilea caz,
pentru implementarea de metode anti-debugging am propus realizarea unui program de protecţie
automată a fişierelor executabile şi am pus la dispoziţie în anexa 3 codul sursă al celor mai
importante funcţii din program.
26

Am scris codul sursă al programului în limbaj de asamblare, utilizând mediul de programare Winasm
Studio care utilizează sintaxa MASM (Microsoft Macro Assembler) evindeţiind astfel posibilitatea
elaborării propriului mecanism de protecţie cu instrumente distribuite gratuit.
La implementarea programului de protecţie automată am pornit de la algoritmi elementari pe care iam
extins, elaborând algoritmi complecşi de securitate. Am ţinut cont de implementarea modulară care să
permită actualizarea algoritmilor de oricâte ori este nevoie. Principala caracteristică a programului de
protecţie este maleabilitatea, el permiţând o configurare şi o modificare a opţiunilor de protecţie, testate în
capitolul 6. Datorită faptului ca performanţele programului protector sunt măsurabile, dimensiunea şi
fiabilitatea acestuia se pot ajusta în funcţie de opţiunile de protecţie utilizate. Orice program nou de
protecţie automată a fişierelor executabile se testează evaluând performanţele şi nivelul de securitate
pentru a descoperi eventualele vulnerabilităţi şi a le elimina. Pe durata testului este foarte important să
existe instrumente care să ofere informaţii despre performanţele şi comportamentul programului. Astfel
de instrumente pot fi programele debugger iar în testele efectuate noi am utilizat Ollydebugger prezentat
în paragraful 2.4.
Capabilităţile programului protector cresc considerabil timpul de debugging datorită dimensiunii
componentei depacker şi metodelor de criptare şi obfuscare a codului programului protejat.
Am ţinut cont de etapele parcurse de crackeri la analiza unui program executabil, şi anume
identificarea limbajului de programare utilizat, citirea resurselor text ale fişierului executabil, citirea
numelor funcţiilor API importate, identificarea şi analiza rutinei de protecţie a programului, în interiorul
secţiunii de cod a fişierului executabil.
Astfel punctul iniţial în protecţia automată a fişierelor executabile a fost identificarea unui debugger
activ în memorie şi eliminarea acestuia, metodă numită anti-debugging. Soluţia cea mai simplă în
rezolvarea acestei probleme este apelarea, din componenta depacker, a funcţiei IsDebuggerPresent. Alte
soluţii constau în identificarea numelui debuggerului în memorie şi împiedicarea încărcării fişierului
executabil în acelaşi timp cu debuggerul.
Am continuat cu criptarea tuturor resurselor text, adică mesaje afişate la execuţie, numele fişierelor
librărie importate, ale funcţiilor API apelate, şi realocarea punctului de intrare în programul executabil.
S-au dezvoltat metode anti-dumping precum cod care se automodifică la execuţie numit cod
polimorfic şi s-au implementat metode de înlocuire a codului original cu porţiuni de cod echivalent
numite transformări metamorfice. Tot ca metodă anti-debugging s-a implementat o rutină de
redirecţionare a tabelei de importuri a fişierului protejat astfel încât, dacă în urma analizei cu un
debugger, se atinge punctul de intrare original, versiunea descărcată a fişierului executabil din memorie să
nu funcţioneze.
Programul protector citeşte toţi parametrii de bază ai fişierului protejat, prezentaţi în capitolul 3, şi îi
modifică sau îi realocă în spaţii de memorie rezervate. Înainte de efectuarea oricărei operaţii asupra
fişierului executabil acesta se va salva într-o copie de siguranţă, pe hard-disk.
Am dezvoltat un algoritm de protecţie a programelor executabile cu număr serial utilizând noţiuni de
calcul matricial. Nu am folosit algoritmi existenţi deoarece aceştia sunt populari deja în comunităţile de
crackeri de pe internet şi am dorit să implementez o schemă originală de protecţie a programelor.
Prin urmare, am extins cifrul Hill de la criptarea cu o singură matrice inversabilă, la criptarea cu două
matrice, cu ajutorul noţiunii de matrice aritmetic echivalente. Problema liniarităţii acestui algoritm s-a
rezolvat prin implementarea unor transformări neliniare de tip pseudo-Hadamard, cifruri cu substituţie şi
transformări ciclice asupra elementelor matricelor de stare. Acestea au ca rezultat difuzia criptografică şi
eliminarea completă a liniarităţii algoritmului. Implementarea algoritmului de criptare am efectuat-o în
limbaj C, în care am intercalat rutine de criptare în limbaj de asamblare, utilizând numeroase operaţii
aritmetice şi logice, bucle de verificare, pentru aruncarea crackerilor pe piste false în scopul creşterii
27

timpilor de debugging. Tot ca metodă de protecţie am implementat rutina de verificare a numărului serial
într-un fişier .DLL separat, protejat automat cu programul protector, din care funcţiile apelate se încarcă
dinamic în memorie. Acest fişier .DLL nu se va încărca în întregime în memorie pentru a nu putea fi
decriptat şi citit cu un debugger.
Datorită numărului de matrice de criptare, care depinde de mulţimea de matrice selectată, se verifică
matematic că mulţimea respectivă este infinită, eliminând criptanaliza prin forţă brută a algoritmului de
criptare.
Utilitatea algoritmului de criptare reiese din implementarea acestuia într-un limbaj de programare şi
utilizarea lui la verificarea numerelor seriale utilizate la protecţia de programe de calculator. Se
recomandă verificarea de porţiuni ale numerelor seriale şi nu a întregului şir de caractere care compune
numărul serial.
Algoritmul de criptare a fost testat cu OllyDebugger obţinând rezulate foarte bune, generalizarea
cifrului Hill propusă în acestă teză fiind o soluţie fiabilă la protecţia programnelor executabile.
Ca şi concluzie finală, în urma testelor efectuate cu programul protector dezvoltat în cadrul acestei
teze, al cărui cod sursă este pus la dispoziţia programatorilor, acesta oferă o soluţie fezabilă de protecţie a
fişierelor executabile.
7.2 Contribuţii
Activitatea de cercetare desfăşurată pentru elaborarea acestei teze a necesitat cunoştinţe din
domeniul electronicii, precum limbajul de asamblare al microprocesoarelor 8086, al programării
calculatoarelor şi instrumente software. Munca depusă a adus câteva contribuţii originale în fiecare din
aceste domenii, şi urmează a fi enumerate în continuare.
Am efectuat un studiu al metodelor actuale de protecţie a programelor de calculator. La efectuarea
studiului am exploatat părţile vulnerabile ale unui fişier executabil, prezentate în paragraful 2.2, cu
ajutorul unor instrumente software prezentate la rândul lor în paragrafele 2.3 şi 2.4. Etapele acestui studiu
au fost:
Selectarea unui eşantion format din peste 400 de programe în versiune shareware, comercializate
pe internet. Toate aceste programe au avut în comun faptul că aveau implementată o schemă cu
număr serial pentru activare. Alegerea programelor s-a făcut aleator sau în funcţie de preţul şi
popularitatea lor.
Instalarea fiecărui program în parte şi apoi încărcarea fişierului executabil în Olly Debugger,
prezentat în paragraful 2.4. Fişierul executabil analizat îl definim ca fişier ţintă.
Rularea programului ţintă din contextul debuggerului şi urmărirea atentă a execuţiei acestuia. Am
dedus faptul că toate programele fără protecţie antidebugging rulează perfect în contextul
debuggerului şi logica programului în cod asamblare poate fi urmărită de la început până la sfârşit.
Accesarea cu ajutorul debuggerului, în primul rând, a resurselor text şi a tabelei de importuri a
fişierului ţintă si setarea unor puncte de întrerupere pentru oprirea execuţiei înainte de verificarea
numărului serial.
Analiza codului asamblare corespunzător rutinei de protecţie, şi notarea tuturor vulnerabilităţilor
acesteia, în funcţie de logica implementată. Rezultatele sunt prezentate în paragraful 2.6.
Am făcut un studiu al programelor de protecţie automată a fişierelor executabile şi am obţinut rezultate
legate de fiabilitatea acestora anume: intrarea în conflict cu programe antivirus şi cu versiuni ale
sistemului de operare Windows.
28

După efectuarea acestor studii am continuat cu optimizarea şi elaborarea de soluţii originale de
protecţie a programelor de calculator, unele rezultate fiind publicate şi în lucrările din [anexa 1] şi [anexa
2]. Metodele originale elaborate în această teză sunt:
Algoritmi noi de criptare şi validare a numerelor seriale în scopul încetinirii procesului de
debugging. Aceşti algoritmi şi utilitatea lor sunt prezentate în capitolul 5 din teză. Am extins
algoritmul de criptare Hill prin utilizarea noţiunii din agebra liniară, de matrice aritmetic
echivalente, şi am distrus liniaritatea algoritmului Hill prin inserarea de transformări neliniare din
algebra computaţională, asupra elementelor matricelor de stare corespunzătoare numerelor seriale
sau blocurilor de număr serial criptate. Am implementat aceşti algoritmi în limbaj C într-un fişier
librărie DLL separat şi am elaborat o soluţie a problemei încărcării întregului algoritm în memorie
în acelaşi timp, prin alocarea dinamică de memorie numai blocurilor de cod utilizate la un
moment dat, apelând funcţiile LoadLibrary şi GetProcAddress.
Metode originale de distrugere a logicii codului asamblare protejat prin obfuscare statică şi
dinamică, prezentate în paragrafele 4.2.5 şi 4.2.6. La obfuscarea statică [anexa 1] am elaborat
bucle menite să creeze diversiuni în executarea codului protejat şi să arunce crackerii pe piste
false. Am utilizat bucle simple cu constantă de inducţie mare incrementată sau decrementată şi
bucle care comunică între ele prin modelul buclă principală-bucle secundare, cu constante de
inducţie mari corespunzătoare fiecărei bucle. La obfuscarea dinamică [anexa 2] a codului protejat
am elaborat un motor metamorfic în scopul inserări automate de blocuri de cod în codul protejat.
Etapele proiectării motorului metamorfic sunt:
1. Definirea variabilei care conţine întregul bloc de cod care se va insera;
2. Definirea variabilei care conţine dimensiunea codului de bloc inserat;
3. Implementarea unei funcţii de inserare a blocurilor de cod definite anterior.
Am elaborat un set de reguli pentru buna funcţionare a motorului metamorfic:
1. instrucţiunile în limbaj de asamblare inserate să nu utilizeze ca operanzi registre utilizate în
prealabil ca operanzi ai instrucţiunilor de marcare a începutului de bloc inserat şi lungimii
de cod inserat;
2. inserarea blocurilor de cod să nu împiedice fluxul de execuţie a codului protejat. Astfel,
vom evita inserarea în interiorul unor bucle sau porţiuni de program criptate polimorfic.
3. codul inserat se va executa într-o buclă cu constantă de inducţie mare. Din acest motiv vom
avea în vedere dimensiunea blocului inserat deoarece se pot obţine erori de execuţie a
codului protejat, datorită intervalelor unor instrucţiuni de ciclare în limbaj de asamblare.
De exemplu, în cazul utilizării instrucţiunii de ciclare LOOP se vor utiliza blocuri de cod
cu dimensiunea în domeniul [-127, +127], noi am utilizat blocuri de cod cu dimensiunea -
124 respectiv +124. Deoarece blocurile mici nu asigură un nivel optim de securitate am
utilizat instrucţiuni de salt în bucla care conţine codul inserat de către motorul metamorfic.
Astfel, am efectuat următoare înlocuire:
start_bucla: cu start_bucla:
corp bucla corp bucla
LOOP start_bucla DEC ECX
TEST ECX, ECX
JZ sfarsit_bucla
JMP start_bucla
sfarsit_bucla: continuare program
29

Cu ajutorul motorului metamorfic se pot insera blocuri de cod de dimensiuni diferite în codul protejat,
respectând regulile de mai sus. Formula (1) pe care am elaborat-o şi conform căreia se generează întreg
tabelul de instrucţiuni în limbaj de asamblare care urmează a fi inserate cu motorul metamorfic este,
[anexa 4]:
De exemplu,
DD număr_octeţi
DD octeţi instrucţiune în notaţie little endian (1)
DD octeţi instrucţiune în notaţie little endian
DD număr octet inserat aleator.
DD 2
DD 000EB80h ;add bl, 0
DD 000EB80h ;add bl, 0
DD 2
înseamnă că instrucţiunea inserată este pe 2 octeţi din care al doilea este generat aleator. Pentru generarea
aleatoare atât a octeţilor cât şi a blocurilor de cod am utilizat funcţiile srand şi GetTickCount. Am elaborat
un tabel de 22 blocuri de instrucţiuni pe maximum 3 octeţi. Am inserat blocuri de cod cu lungimea de
1024=1Ko, 2048=2Ko, 3072=3Ko, 4096=4Ko, 5120=5Ko, optimizând dimensiunea şi viteza de execuţie
a programului protejat cum a fost prezentat în capitolul 6. Pentru a oferi codului protejat un caracter
dinamic am inclus în tabelul cu instrucţiunile asamblare inserate trei tipuri de instrucţiuni JMP-JMP,
JMP-CALL, CALL-JMP, RET-JMP şi JMP-RET. Datorită limitării numărului de octeţi ai fiecărei
instrucţiuni la 3 nu am putut utiliza instrucţiuni de tip CALL-CALL, CALL-RET sau RET-RET, fiecare
din aceste instrucţiuni fiind reprezentată pe 8 octeţi. La inserarea instrucţiunilor de salt în codul protejat
nu am introdus operand aleator pentru a nu întrerupe fluxul de execuţie al programului protejat.
Am împiedicat analiza programului protejat prin metode de întrerupere a încărcării şi execuţiei
acestuia în contextul unui debugger.
Contribuţiile prezentate s-au fructificat într-un program de protecţie automată a programelor de
calculator, respectiv a fişierelor de tip executabil, al cărui cod sursă este prezentat în anexa 3.
La implementarea acestui program am elaborat o metodă originală de reconstruire şi redirecţionare a
tabelei de importuri a programului protejat, aşa cum s-a prezentat în capitolul 4, fie prin ştergerea tuturor
elementelor vectorului DataDirectory şi reconstruirea ulterioară acestora, fie prin criptarea tuturor
numelor fişierelor librărie şi funcţiilor importate şi apoi apelarea acestora prin intermediul componentei
depacker a programului protector utilizând funcţiile LoadLibrary şi GetProcAddress.
În concluzie contribuţiile aduse în această teză se adresează cerinţelor de protecţie a programelor de
calculator de pe piaţă, si anume:
elaborarea de transformări metamorfice ale codului asamblare fără semnături constante în
porţiunile de cod protejate;
distrugerea totală a logicii codului asamblare protejat;
detectarea şi împiedicarea executării programelor debugger, în special Olly Debugger;
protecţia codului încărcat eventual in debugger;
protecţia tebelei de importuri;
schemă originală de protecţie cu număr serial.
30

7.3 Direcţii de cercetare ulterioară
Ca direcţii de cercetare ulterioară enumerăm:
Dezvoltarea de noi algoritmi de obfuscare a codului în limbaj de asamblare a unui fişier
executabil.
Dezvoltarea unui model nou de motor metamorfic pentru înlocuirea porţiunilor de cod cu
altele echivalente ca funcţionalitate.
Dezvoltarea unei metode noi de realocare a tabelei de importuri a unui fişier executabil.
Dezvoltarea de noi algoritmi de protecţie a numerelor seriale.
Elaborarea de metode noi anti-debugging şi anti-dumping.
Elaborarea unui nou model matematic pentru care să stea la baza unui algoritm de criptare a
parolelor sau numerelor seriale.
31

BIBLIOGRAFIE
[1] Amoroso, E. G.: Fundamentals of Computer Security Technology, Prentice Hall PTR, 1994
[2] Anderson R.: Security Engineering, John Wiley & Sons, 2001
[3] Aucsmith D.: Tamper Resistant Software: an implementation, Proceedings of the First International
Information Hiding Workshop, Lecture Notes in Computer Science 1174, Springer-Verlag, Cambridge,
UK, pp. 317-334, 1996
[4] Bishop M.: Computer Security: Art and Science, Addison Wesley, 2003
[5] Blake I., Seroussi G., Smart N.: Elliptic Curves in Cryptography, Cambridge University Press, 2000
[6] Brown K.: Programming Windows Security, Addison-Wesley, 2000
[7] Cerven P.: Crackproof Your Software: Protect Your Software Against Crackers, No Starch Press,
2002
[8] Danehkar A.: Inject Code Inside Import Table, http://www.codeproject.com/KB/applications
[9] Petrean L.: Software Security – Polymorphic and Metamorphic Code Applications, SIITME 2007
International Symposium for Design and Technology of Electronic Packaging, pp. 212-217, Baia Mare,
Romania, ISSN 1843-5122
[10] Petrean L.: Software Security – General Method of Literal Strings Obfuscation, IWCIT 2007
International Workshop Control and Information Technology, pp. 41-46, Ostrava, Czech Republic, ISBN
978-248-1567-1
[11] Petrean L., Toderean G.: Portable Executable Format Security Patterns, IWCIT 2008 International
Workshop Control and Information Technology, pp. 170-174, Gliwice, Polonia, EAN-9788390474380
[12] Petrean L., Toderean G.: Portable Executable File Format – Import Address Table Redirection and
Reconstruction, microCAD 2008 International Scientific Conference 20-21 March 2008, pp. 49-54,
Miskolc, Ungaria, ISBN 978-963-661-812-4
[13] Petrean L., Toderean G.: Assembly Metamorphic Code Transformations as a Protection Method Of
Portable Executable Files, microCAD 2009 International Scientific Conference 19-20 March 2009, Vol.
XXIII, pp. 35-40, Miskolc, Ungaria, ISBN 978-963-661-866-7
[14] Pirogov V.: The Assembly Programming Master Book, A-LIST Publishing, 2005
[15] Pirogov V.: Disassembling Code: IDA Pro and SoftIce, A-List Publishing 2006
[16] Stamp M.: Information Security Principles and Practice, John Wiley & Sons, 2006
32

Curriculum Vitae
Liviu Petrean
Profesor de matematica la Liceul Teoretic “Emil Racovita”
56, Bd Republicii Apt. 43, Baia Mare 430231 email: liviupetrean@yahoo.com
Tel. +4 0362 417 045
DATE PERSONALE : Născut la 04 August 1972, în Baia Mare
LIMBI STRAINE : Engleza, franceza
STUDII:
- 1990-1995, Universitatea Baia Mare, Facultatea de Litere si Ştiinţe, specializarea matematicăfizică
cu durata studiilor de 5 ani;
- 1998-2001, Universitatea “Politehnica” din Timişoara, profilul Ştiinta Sistemelor şi a
Calculatoarelor, specializarea Informatică Tehnică, cu durata studiilor de 3 ani, şcolarizare la
Universitatea de Nord din Baia Mare;
- 2001-2003, Universitatea Tehnică din Cluj-Napoca, Studii Academice Postuniversitare,
specializarea: Informatică Aplicată si Programare.
ACTIVITATE PROFESIONALA:
- 1995-1997, Profesor de informatică la Grupul Şcolar “Aurel Vlaicu” din Baia Mare, str Gh
Marinescu nr. 1;
- 1997-2003, Profesor de matematică la Liceul Teoretic “Emil Racoviţă” din Baia Mare, str. V
Alecsandri nr. 56;
- 2003-2006, Profesor de matematică la Lake Marion High School, 3653 Tee Vee Road,
Santee, SC 29142, USA, Director: Rose Pelzer-Brower.
- 2006-2007, Profesor de matematică la Cathedral Hall Academy, 803 Howard Pkwy, Myrtle
Beach, SC 29577, USA, Director: Sue O’Hearn, Dr. Reginald Wayne Miller;
- In prezent sunt profesor titular de matematică la Liceul Teoretic “Emil Racoviţă” din Baia
Mare.
TEME DE INTERES:
- Detectarea şi contracararea programelor de dezasamblare şi a punctelor de întrerupere în
execuţia unui program;
- Creşterea gradului de dificultate al analizei programelor executabile dezasamblate;
- Tehnici de protecţie a programelor executabile.
PREMII, DISTINCTII :
ETS Recognition of Excellence (top 15% of all testers who took this assessment in previous
years), Mathematics: Content Knowledge, on September 13, 2003.
33