Obfuscare - problema disassembly

Salutare! Intampin o problema in a dezasambla un executabil(folosesc intel xed). Procedez astfel:
Transform imaginea  programului in hexa,caut  sectiunea .txt si o dau la functiile din intel xed(primeste cate 15 biti) spre dezasamblare.
Problema apare cand incearca sa dezasambleze aceste bucati. Incercand cu un soft de dezasamblare am observat ca se obtine opcodu din bucati de 15 biti combinate gen:
cc 55 8b ec 81 ec c0 00 00 00 53 56 57 8d bd
40 ff ff ff b9 30 00 00 00 b8 cc cc cc cc f3 - eroare

opcodu s-ar obtine din: 8d bd 40 ff ff ff         lea edi, dword [ ebp + 0xffffff40 ]

Intrebarea este cum fac sa calculez secventele de genu "8d bd 40 ff ff ff" inainte sa le dau spre dezasamblare?

Incearca cu OllyDbg

Mie imi trebuie opcodul generat de programul meu in c cu ajutorul framework-lui intel xed. Primesc ca si input un executabil.

Mai intai nu e vorba de 15 biti ci bytes. Mai apoi, si cel mai important, este ca se pare ca nu ai inteles bine ce e cu acel ‘15’. Instructiunile IA32/IA64 au maxim 15 octeti (cel putin asa zic autorii xed, nu stiu daca valoarea e corecta), nu exact 15. In plus, in segmentul de cod (.text) nu este obligatoriu sa fie doar instructiuni una dupa alta, ci pot fi si zone neutilizate sau date.

Deci dezasamblarea e o chestie foarte complicata. Trebuie sa pornest dintr-un punct unde sti ca trebuie sa inceapa o instructiune, cum ar fi adresa de pornire a programului data in antetul fisierului *.exe, si sa dezasamblezi tinund cont de lungimea fiecarei instructiuni intalnite. In plus trebuie sa urmaresti instructiunile de salt (jmp/ jcond/ call/ ret/ etc) pentru ca ele iti dau adrese noi de unde sa continui; de asemena dupa un salt neconditionat este posibil sa nu mai urmeze cod.

Edited by sags, 22 April 2017 - 17:06.

Am inteles. Cred ca algortimul ar fi recursiv,daca sare intr-o functie si nu este cod. Cum as putea sa aflu lungimea fiecarei intructiuni(eu daca stiu doar codu in hexa)?

Cauti pe net ‘Intel® 64 and IA-32 Architectures Developer's Manual’, si din cele multe-multe pagini (4-5 mii) afli tot ce vrei. Printre altele ai si modul de codificare a instructiunilor de unde poti elabora un algoritm care, dandu-se o secventa de octeti despre care stii ca incepe cu o instructiune, sa iti spuna cat e lungimea acelei prime instructiuni. Dar nu cumva xed te poate ajuta? Adica tot trebuie sa ii dai un sir de octeti sa o decodeze (ii dai maximul posibil, 15), nu iti spune si cati octeti a ‘consumat’ din ea pentru prima instructiune de care a identificat-o?

LE: De fapt, ce anume exact vrei sa faci? Scrii ca e ‘programul tau’ si e ‘in C’. Deci ai sursele, nu? Stii ca practic orice compilator are optiuni in linia de comanda sa iti scoata un fisier ‘listing’ cu codul generat? Si atunci nu mai e nimic de dezasamblat…

Edited by sags, 22 April 2017 - 17:33.

Nu cred sau nu-mi dau eu seama?!?!
[ http://i63.tinypic.com/25qw2sw.jpg - Pentru incarcare in pagina (embed) Click aici ]

Edited by Alex99_1, 22 April 2017 - 17:38.

CC este instructiunea int 3 (una din codificarile posibile ale ei), de un singur octet. Este vorba de o intrare in debugger (sau abandonarea programului). Deci urmeaza sa continui dezasamblarea dupa acel octet CC (‘consumi’ unul singur). Din poza pe care ai pus-o nu vad unde ar fi lungimea instructiunii decodificate. Cauta totusi prin ceva documentatie a xed, poate zice acolo - e mult mai sigur decat sa o iei pe ghicite. Daca nu, IA32/64 Reference nu are decat 4700 de pagini…

Chestia este ca unele compilatoare (nu stiu daca toate) umplu cu CC zonele, de regula de date, neinitializate. Scopul este se declanseze debugger-ul daca se ajunge din greseala cu executia pe acolo. Deci zone pline cu CC = poate fi zona de date, adica sa nu fi nimerit bine .text..

Edited by sags, 22 April 2017 - 17:53.

Am sa pun tot programul cu toate sectiunile si am sa caut prin documentatie. O sa revin cu intrebari

Alex99_1, on 22 aprilie 2017 - 17:11, said:

Cu LDE:
http://beatrix2004.f...e/download1.php
http://www.beaengine...d/LDE64-x86.zip
http://www.beaengine...d/LDE64-x64.rar

Ar fi ceva,am sa incerc. Proiectul asta este un obfuscator care primeste ca input un executabil(doar x86 pecoff) si face modificari in cod asm. Le encodeaza inapoi si programul trebuie sa mearga la fel.

Sanse sa modifici codul existent ‘pe loc’ si dupa modificare programul sa mai si functioneze sunt nule. Inlocuind instructiuni se modifica lungimile lor deci si adresele de inceput ale instructiunilor. Cum nu poti sti (cu un efort decent, si nici macar cu unul in-decent ) care sunt toate adresele destinatie ale salturilor, dupa modificare te trezesti ca se face un salt de cine stie unde in mijlocul unei instructiuni pe care ai pus-o tu; si chiar daca le-ai cunoaste, e cam greu sa rescrii secvente de cod pastrand limite de instructiuni atat de dese.

Ce ai putea face este sa adaugi cod de pornire personalizat, caz in care nu ai nevoie sa dezasamblezi nimic fiindca tratezi programul original ca o cutie neagra.

• Codul pe care il adaugi va primi controlul la lansarea programului si va modifica in memorie zona care corespunde programului original ca sa il de-obfuscheze, apoi ii va preda controlul.
  
• Pe disc fisierul *.exe va contine programul original obfuscat plus loaderul tau.
  
• Modifici in antet adresa de lansare a.i. sistemul de operare sa predea controlul catre loaderul tau.
  
• Atentie la fixup-uri, pe acestea operatiile de ‘obfuscare’ si ‘de-obfuscare’ trebuie sa le ocoleasca.
  
• Bineinteles pentru modificarea fisierelor *.exe vei scrie un alt program care preia informatiile despre programul original din antet, obfuscheaza codul original, adauga loader-ul tau la sfarsit, apoi modifica antetul in mod corespunzator (sa tina cont de lungimea mai mare si punctul de pornire sa fie in codul tau). Nu stiu exact cum sa adaugi cod suplimentar (poate o sectiune noua - dar nu mai tin minte cum e organizat PE) fara sa nu deplasezi sectiunile care vin dupa .text.
  
• Atentie ca procesoarele Intel preiau si chiar executa provizoriu instructiuni in avans, chiar si unele la care nu se va ajunge niciodata, plus ca au tot felul de memorii cache. Cum tu ajungi de fapt sa ai cod automodificabil, trebuie sa te asiguri ca ‘faci curatenie’ in aceste cache-uri. O buna parte din cele 4700 de pagini de care ti-am zis iti vor fi foarte necesare…

A, si sa nu te mire daca la final programele antivirus/ AntiMalware vor detecta programul modificat ca virus, cracker sau ‘potentially unwanted program’.

Edited by sags, 22 April 2017 - 19:58.

Prin obfuscheaza codul original te-ai gandit ca il cripteaza sau nush(ii face XOR cu o cheie),iar apoi cand se executa programul. Loaderul il decripteaza si apoi programul ruleaza normal?

sags, on 22 aprilie 2017 - 17:25, said:

Alex99_1, on 22 aprilie 2017 - 20:11, said:

Da, asa ceva am vrut sa spun. Daca vrei mai mult, cum ar fi sa se decodifice pe bucati dupa cum e nevoie de diferite fragmente in timpul executiei sau sa faca diferite verificari de ‘licenta valida’ in timpul executiei, atunci iti trebuie sursa sa o modifici. Sa pornesti de la un program oarecare si in el ‘sa faci modificari in asm’, sansele de reusita sunt nule.

Am inteles. O incerc ce ai spus. Sa fac un program care imi cripteaza programul input si ii adauga un loader pentru decriptate.

Edited by Alex99_1, 23 April 2017 - 12:02.

Deci, dupa 16 postari, concluzionam ca vrei sa faci o solutie de obfuscare?

Da.Asa este! Si nu am sursele de la ce programe primesc doar .exe