Obfuscare - problema disassembly

In jmp near si call near operandul (cei 4 bytes) indica diferenta intre 2 adrese de memorie (adresa destinatiei - adresa instructiinii de dupa jmp/ call). Oriunde in memorie s-ar incarca imaginea programului aceste valori nu se schimba (‘cod independent de pozitie’) si prin urmare locul unde se gasesc ele in imagine nu este semnalat in nici un fel.

Din contra, operandul lui push in aceasta situatie trebuie sa fie adresa de memorie (offsetul in segment) unde sa continue executia dupa retn ce va fi executat. In functie de adresa de incarcare a imaginii, aceasta valoare trebuie modificata.

Din ce stiu un PE are o adresa de baza pentru care a fost creat. Toate valorile de tipul celei din push-ul de mai sus sunt completate in fisierul EXE ca si cum imaginea este incarcata la aceasta adresa de baza. Dar pentru ca loader-ul sa stie ce si unde sa modifice in caz ca imaginea e incarcata la alta adresa, toate locurile unde sunt aceste valori trebuie/ sunt trecute intr-o lista de relocari (fixup-uri).

Tu completezi aceasta lista in momentul in care scrii operanzii instructiunilor push? Fiindca din ce vad in poze diferite imagiunea NU este incarcata la ceeasi adresa (uneori ai 0401×××× alteori 00EE××××) si deci aceste fixup-uri chiar conteaza. (Oricum in cazul general sunt necesare fiindca nu ai garantia ca imaginea poate fi incarcata la adresa ei ‘standard’.)

Cumva in acel OllyDbg zonele relocabile apar subliniate cu o linie alba in partea de cod hexa? Ca din poze mie asa mi se pare. Mai observ ca operanzii din push nu sunt subliniati si nici nu s-au modificat cand adresa de baza s-a modificat.

Nu pot sa imi dau seama daca aceasta e cauza imediata a erorii pe care o obtii dar poate fi una din ele. Alta ar putea fi ca din capu’ locului calculezi gresit operandul lui push; cinstit sa fie nu imi dau seama de unde poate proveni acel 00000BA5.

politete, on 02 octombrie 2017 - 17:24, said:

Eu mai observ ca eip = 00EE33BC, adica in cu totul alta parte decat retn marcat cu fond albastru.

Edited by sags, 02 October 2017 - 20:07.

Ai dreptate trebuie adresa din memorie(VA),dar pe programul care am testat si nu merge(e compilat cu VS 2015),iar pe altul unu mai simplu si mic merge si nu inteleg de ce(in programul meu in c cand mapeaza lab1_prog.exe in memorie VA=imgBase+RVA => 0x411000) O sa las imagini:
https://imgur.com/qiVcNT2
https://imgur.com/eBsOc0c

Asta e problema se pare, lista de fixup-uri?

Edited by Alex99_1, 02 October 2017 - 21:08.

Da, din poze cred ca intr-adevar problema este lipsa fixup-urilor. Ca sa fii sigur, vezi daca operandul lui push se modifica (probabil acum NU) atunci cand imaginea e incarcata la alta adresa; ar trebui sa se modifice cu aceeasi diferenta, de exemplu daca imaginea e incarcata la adrese cu 00EE0000 mai mari atunci exact cu atat trebuie sa creasca si operandul lui push. Dar daca programelul tau cu care modifici exe-uri nu creeaza acea tabela de relocari, de unde iti inchipui tu ca poate aparea una?

Si mai fii atent ca acea tabela trebuie actualizata si in cazul in care modifici cod existent, daca se intampla sa atingi si zone cu valori relocabile. In cazul particular ca modifici un call near intr-un jmp near, aceste instructiuni sunt independente de pozitie si nu ai nimic special de facut, dar acel push imediat al adresei de retur NU este independent de pozitie. Daca te apuci sa faci alte modificari trebuie sa fii atent si la eventualele fixup-uri preexistente care trebuie modificate/sterse si la cele care trebuie eventual create.

Edited by sags, 02 October 2017 - 21:32.

este corect ce spui

Din cate am inteles un executabil nu are nevoie de sectiunea .reloc. Am sters .reloc din "lab1_prog.exe" si push-urile imi sunt recunoscute,dar programul nu ruleaza(in olly cand il incarc imi spune "Bad or unkown format of 32-bit executable" si nu stiu de ce). Acum intreabarea mea este: are rost sa ma complic sa fac fixup-urile?adica indiferent de ce executabil primesc ca input eu sterg .reloc si fac modificarile la call. O sa-mi meraga tot timpul programul modificat?

Edited by Alex99_1, 03 October 2017 - 14:20.

Da, are rost sa te ‘complici’ cu relocarile, ele sunt necesare (a se citi indispensabile).

Dar daca vrei neaparat sa te faci ca faci ceva si nu chiar sa faci acel ceva, am impresia ca exista o scapare (cu niste costuri la partea de portabilitate): IMAGE_FILE_RELOCS_STRIPPED aici <https://msdn.microso...ject_and_image_>. (Nu am mai avut de-a face cu asa ceva de multi ani si amintirile se mai sterg, deci nu stiu sa iti spun sigur ce si cum.)

Edited by sags, 03 October 2017 - 18:48.

Din ce am citit si inteles nu ar fi complicat deloc sa fac ajustarea la adresele de la fiecare call din sectiunea .text.

As an example, if you find the relocation information to be
0x00004000	 (32 bits, starting RVA)
0x00000010	 (32 bits, size of chunk)
0x3012		 (16 bits reloc data)
0x3080		 (16 bits reloc data)
0x30f6		 (16 bits reloc data)
0x0000		 (16 bits reloc data)
0x00000000	 (next chunk's RVA)
0xff341234
you know the first chunk describes relocations starting at RVA 0x4000 and
is 16 bytes long. Because the header uses 8 bytes and one relocation
uses 2 bytes, there are (16-8)/2=4 relocations in the chunk.
The first relocation is to be applied to the DWORD at 0x4012, the next
to the DWORD at 0x4080, and the third to the DWORD at 0x40f6. The last
relocation is a no-op.
The next chunk has a RVA of 0 and finishes the list.
Now, how do you do a relocation?
You know that the image *is* relocated to the preferred load address
'ImageBase' in the optional header; you also know the address you did
load the image to. If they match, you don't need to do anything.
If they don't match, you calculate the difference
ACTUAL_BASE - PREFERRED_BASE
and add that value (signed, it may be negative) to the relocation
positions, which you will find with the method described above.

Presupun ca ar fi ceva de genu. In programul meu in c ImageBase e 0x400000(pt lab1_prog.exe").
ex: 0x5000000 - addr la care loaderu imi incarca programu
0x400000 - imageBase
delta = 0x5000000-0x400000 = 0x4c00000 (care e adunat la imageBase si cam asta ar fi cred)
Problema e ca nu stiu cum sa aflu la ce adresa s-a decis loaderu sa incarce programul?

Edited by Alex99_1, 05 October 2017 - 18:54.

Tocmai asta e, ca NU ai de unde sa stii la ce adresa s-a decis loaderu’ sa incarce programul. De aceea exista informatiile de relocare: sa ii spuna loader-ului unde sa faca ajustarile necesare.

In fisierul *.exe tu completezi operandul lui push, care este adresa de retur din rutina pe care vrei sa o apelezi cu-jmp-in-loc-de-call, ca si cum programul ar fi incarcat la adresa de baza preferata. In plus, creezi o intrare in tabela de relocari pentru ca loader-ul sa stie ca la adresa … (unde e acel operand) exista un DWORD care trebuie ajustat in caz ca programul e incarcat la alta adresa de baza decat cea preferata. Ajustarea de care scrie in citatul dat mai sus, ‘calculate the difference ACTUAL_BASE - PREFERRED_BASE and add that value (signed, it may be negative) to the relocation positions’, o face loader-ul, nu o faci tu cand scrii in *.exe. Ai face-o ‘TU’ daca acel ‘TU’ ai fi loader-ul (in acest sens pare scris acel text).

Ceea ce nu inteleg eu este cum se fac calculele:
in programul meu c am VA(citit din exe)=RVA+ImageBase (0x411000 tot timpu)
iar in ollydbg cand incarc programu VA gen 0x1031000(de ex)
https://imgur.com/PytG2Ao
Prin calcule face el de ii da o adresa asa mare?
Cu PeView talelu de realocari arata asa:
https://imgur.com/4hHCUNo

Am gasit si aici explicat,dar tot nu ma prind cum face:
http://bytepointer.c..._format_pt2.htm

Revin cu o alta intrebare. Poate cineva sa-mi dea exemplu sau vreo idee de obfuscare raw in asm(insert junk code or something)?

Vezi poate te ajuta lucrarea asta https://www.duo.uio.....pdf?sequence=1
Este despre detectia de junk instuctions dar pana la urma depinde doar din care parte privesti lucrurile

Update la link te rog. 404 Not Found.

Sorry. Lucrarea se numeste "Detection of Junk Instructions in Computer Viruses" si e a lui Martinsen.
Asta e link-ul de acum https://www.duo.uio.....pdf?sequence=1
Daca nu-ti merge, pe scholar.google.com https://scholar.goog...r Viruses&btnG= dai click pe link-ul cu tag PDF in dreapta numelui lucrarii.