IVAȘCU LAURENȚIU-MARIAN
Cunoscută ca și Reverse Code Engineering (RCE);
Sau simplu “reversing”.
poate fi folosită pentru :
Înțelegerea conceptului de “malware”;
Înțelegerea conceptului de moștenire a softului.
și nu ar trebui folosită pentru :
Pentru a scoate restricțiile de utilizare a produselor software;
Pentru a găsi și exploata defectele din software;
Pentru a trișa la jocuri, etc.
Presupunem că:
Cel care folosește această tehnică este un atacator;
Atacatorul are doar .exe (nu sursa codului).
Atacatorul ar putea vrea să:
Să înteleagă software-ul;
Să modifice software-ul.
De obicei SRE se concentrează pe Windows.
Deci ne vom concentra pe Windows.
Dezasamblorul:
Convertește .exe pentru a asambla cel mai bine posibil;
Nu poate întotdeauna să dezasambleze corect;
În general ,nu este posibil să asambleze/dezasambleze într-un .exe care rulează.
Depanatorul:
Trebuie să intre prin cod pentru a-l întelege complet;
Munca intensivă, lipsa uneltelor automate.
Editorul HEX:
Folosit pentru a modifica fișierul .exe;
Regmon, Filemon, VMware, etc.
IDA Pro este un dezasamblor de top
Prețul lui este de câteva sute de dolari;
Convertește binarul la asembler.
SoftICE este “alpha si omega” al depanatoarelor
Costul lui este in jur de 1000 de dolari;
Depanatorul pentru Kernel;
Poate depana orice, chiar și OS.
OllyDbg este un depanator shareware foarte bun
Include și un bun depanator.
UltraEdit este bun; freeware.
HIEW
Regmon, Filemon; freeware.
Dezasamblorul oferă rezultate statice:
Imagine bună de ansamblu asupra logicii programului;
Dar trebuie “să execute mental” programul;
Dificil să sară într-un punct specific al codului.
Depanatorul este dinamic:
Se pot pune puncte de întrerupere;
Poate trata codul complex “black box”;
Nu tot codul se dezasamblează corect.
Atât dezasamblorul cât și depanatorul sunt unelte necesare pentru orice activitate SRE.
Cunoștințe practice de assembler;
Experiență de folosire a uneltelor:
IDA Pro: sofisticat și complex;
SoftICE: două mari volume destinate utilizatorilor.
Cunoasterea Windows Portable Executable formatul de fișier (PE);
Răbdare nelimitată și optimism;
SRE este un proces obositor și necesită o muncă intensivă!
Să luăm în considerare un exemplu simplu.
Acest exemplu necesită doar dezasamblorul (IDA Pro) și editorul hex
Trudy desamblează pentru a intelege codul;
Trudy de asemenea vrea să corecteze codul.
De obicei în lumea reală , este necesară și folosirea unui depanator(SoftICE sau OllyDbg)
Programul necesită un număr de serial, dar Trudy nu cunoaște acest număr!
Poate Trudy sa găsească acest număr de serial?
IDA Pro dezasamblează:
Se pare că numărul de serie este S123N456.
Încearcă numărul de serie S123N456.
Funcționează!
Poate Trudy să facă mai mult?
Din nou, IDA Pro dezasamblează:
Și în modul hex…
test eax, eax da SI pentru eax cu el însuși.
Rezultatul este 0 doar daca eax este 0.
Dacă test returnează 0, atunci jz este adevărat.
Trudy vrea ca jz sa fie întotdeauna adevărat!
Poate Trudy să corecteze .exe astfel încât jz să fie întotdeauna adevărat?
Editează serial.exe cu editorul hex:
Îl salvează serialPatch.exe:
Orice număr de serial este corect!
Foarte convenabil pentru Trudy!
Înapoi la dezasamblarea IDA Pro:
Imposibil să prevină SRE în sistemele deschise, dar pot atenua aceste atacuri:
Tehnici anti-dezasamblare: pentru a face confuzie la vederea statică a codului;
Tehnici anti-depanatoare: pentru a face greu accesibilă vederea dinamică a codului;
Rezistenta la sabotare: codul verifica el însuți detectarea acestor sabotări;
Codul de disimulare: face codul sa fie mai greu înțeles.
Metoda anti-dezasamblare include:
Codul criptat;
Falsa dezasamblare;
Auto-modificarea codului;
Multe altele.
Criptarea previne dezasamblarea:
Dar este nevoie de cod pentru a decripta codul;
Aceeași problemă ca și cu virușii polimorfici.
Să presupunem că instrucțiunile de cod sunt:
Ce vede cel care încearcă să dezasambleze:
Acesta este un exemplu de“falsă dezasamblare”;
Atacatorul inteligent își va da seama!
Monitor pentru:
Utilizarea regiștrilor de depanare
Inserarea de puncte de întrerupere
Depanatoarele nu se ocupă de thread-uri foarte bine:
Thread-urile interactive pot induce in eroare depanatorul
Multe alte trucuri ale depanatoarelor-ostile.
Depanatoare nedetectabile sunt posibile în principiu:
Depanare bazată pe hardware(HardICE) este posibilă.
Să presupunem că atunci când programul intră în inst 1,aceasta preia inst 2, inst 3 și inst 4.
Acest lucru este făcut pentru a crește eficiența.
Să presupunem că atunci când depanatorul execută inst 1, ea nu preia alte instrucțiuni.
Putem folosi această diferență pentru a induce în eroare depanatorul?
Să presupunem că inst 1 suprascrie inst 4 în memorie;
Atunci programul(fără depanator) va fi OK întrucât a preluat inst 4 în același timp ca și inst 1;
Depanatorul va fi dus în eroare atunci când ajunge la junk unde inst 4 ar trebui să fie;
Este o problemă pentru program în cazul în care acest segment de cod este executat mai mult decât odată;
De asemenea, codul este foarte dependent de platformă;
Din nou, atacatorul inteligent își va da seama!
Scopul este de a face corectarea mai dificilă;
Codul poate să disperseze părți din el însuși;
În cazul în care apare modificarea, verificarea de dispersie nu reușește;
Cercetările au indicat că se poate obține o bună acoperire a codului cu o mică pedeapsă de performanță;
Dar nu se vrea ca toate verificările să arate la fel;
Sau altceva ușor pentru atacator să elimine verificările;
Această abordare este uneori numită “paznic”.
Scopul este de a face codul greu de înțeles - opusul unei bune inginerie a software-ului;
Un exemplu simplu: codul spaghetti;
Multă cercetare într-o confuzie solidă.
Exemplu: predicatul opac :
int x,y : if((x−y)∗(x−y) > (x∗x−2∗x∗y+y∗y)) {…}
Condiția if() este întotdeauna falsă;
Atacatorul va pierde timp în analizarea unui “cod mort”.
Codul de disimulare este uneori promovat ca o tehnică de securitate puternică;
Ideile originale ale lui Diffie si Helman referitoare la cheile publice criptate erau bazate pe idei similare;
Recent s-a demonstrat că acest cod de disimulare nu poate asigura o securitate puternică;
Disimularea ar putea avea încă utilizări practice, chiar dacă aceasta nu poate fi la de puternică ca si crypto;
Exemplu de autentificare: Software folosit pentru a determina autentificarea
În ultimă instanță, autentificarea este o decizie de tipul first-bit indiferent de metoda folosită
Undeva în software-ul de autentificare, un singur bit determină succesul/eșecul;
În cazul in care atacatorul găsește acest bit, el poate forța autentificarea să fie întotdeauna cu succes;
Confuzia face mai dificil pentru atacator sa găsească acest bit atât de important.
Confuzia
Confuzia forțează atacatorul să analizeze o cantitate mai mare de cod.
Metoda ar putea fi combinată cu:
Tehnici anti-dezasamblare;
Tehnici anti-depanatoare;
Coduri ce verifică sabotarea.
Toate aceste lucruri cresc volumul de muncă (“durerea”) al atacatorului.
Dar un atacator persistent va câștiga în cele din urmă!
Să presupunem că vom scrie o parte a software-ului;
Apoi vom distribui o copie identică (sau clonă) pentru fiecare client;
Dacă un atac este găsit pe o copie , același atac va funcționa pe toate copiile;
Această abordare nu are nici o rezistență la “rupe odată, rupe peste tot”(BOBE);
Aceasta este o situație obișnuită în dezvoltarea de software.
Metamorfismul este folosit în programele de tip malware;
Poate metamorfismul să fie folosit și în scopuri bune?
Să presupunem că scrie o parte de software;
Fiecare copie pe care o distribuim este diferită.
Două nivele de metamorfism sunt posibile:
Toate instanțele sunt distincte din punct de vedere funcțional (posibil în anumite aplicații);
Toate instanțele sunt funcțional identice dar diferă la nivel intern (întotdeauna posibil).
Vom lua în considerare ultimul caz.
Dacă vom distribui N copii ale software-ului clonat: un atac de succes le va sparge pe toate N.
Daca vom distribui N copii metamorfice, în cazul in care fiecare dintre cele N instanțe sunt funcțional identice, dar diferă intern:
Un atac asupra unei instanțe nu va funcționa neapărat împotriva altor instanțe;
În cel mai bun caz, de N ori mai multă muncă este necesară pentru a sparge cel N instanțe.
Nu putem preveni atacurile SRE;
În cel mai bun caz putem spera la rezistența de tip BOBE;
Metamorfismul va îmbunătăți rezistența BOBE;
Să luăm în considerare analogia cu diversitatea genetică:
În cazul în care toate plantele dintr-un câmp sunt genetic identice, o boală poate ucide toate plantele;
În cazul în care plantele dintr-un câmp sunt genetic diverse , o boală poate ucide doar o parte din plante.
Să presupunem că software-ul nostru are un buffer overflow:
Software-ul de tip clonă:
Același atac de tip buffer overflow va funcționa împotriva tuturor copiilor clonate ale software-ului
Software-ul metamorfic:
Instanțe unice; toate sunt funcțional la fel, dar ele diferă în structura internă;
Buffer overflow există în toate instanțele;
Dar un anumit atac de tip buffer overflow va funcționa doar împotriva anumitor instanțe;
Atacurile de tip buffer overflow sunt delicate!
Software-ul metamorfic este un concept intrigant, dar ridică probleme în ceea ce privește:
Dezvoltarea de software;
Upgrade-ul de software,etc.
Metamorfismul nu împiedică SRE, dar ar putea să-l facă infezabil la o scară largă;
Poate fi unul dintre cele mai bune instrumente pentru creșterea rezistenței BOBE;
Metamorfismul este folosit în prezent la programele de tip malware;
Dar metamorfismul nu este folosit doar pentru lucruri rele!