🚀 go-pugleaf

On 24 Cze, 11:46, Bartosz Wójcik <antis...@dont.use.it> wrote:
> Czesc,
>
> Szukam jakichs nowych pomyslow na mutacje kodu x86 w celu utrudnienia jego
> analizy, rozbijanie instrukcji na serie innych, zmiana codeflow, dodawanie
> junkow, instrukcji zasmiecajacych, procedur to juz mam zrobione. Chodzi mi
> o cos, co sprawi, ze kod bedzie jeszcze bardziej trudny do przeanalizowania
> (bez maszyn wirtualnych bo to osobna dzialka).
>

Czesc,
nie są to jakies nowe metody (ale jesli ich nie masz to moga sie
przydac):
- tablica instrukcji rownowaznych w zaleznosci od rozmiaru rozkazow
np:

xor eax, eax <=> mov eax, 0 <=> xor ebx,ebx; mov eax, ebx itp.

- tablica nop-ow w zaleznosci od rozmiarow
nop
mov eax, eax
xchg ebx, ebx itp.

i wrzucanie tego losowo w rozne czesci kodu, sporo fajnych rozwiazan
bylo
w starych (DOS) generatorach VX (jesli dobrze pamietam nazwy to np.
mutagen,
g2 itp.).

Jesli chodzi o zaburzanie przebiegu programu to ukrywanie rozkazow
w innych rozkazach i nastepne skok w "srodek normalnego"  rozkazu
(z glowy przykladu nie podam, bo nie pamietam, ale gdzies w domu
mialem
i jak znajde to podam) bylo kiedys ciekawym rozwiazaniem.

pozdrawiam,
Lukasz

On Tue, 24 Jun 2008 11:46:34 +0200 Bartosz Wójcik
<antispam@dont.use.it> wrote:

> Szukam jakichs nowych pomyslow na mutacje kodu x86 w celu utrudnienia
> jego analizy, rozbijanie instrukcji na serie innych, zmiana codeflow,
> dodawanie junkow, instrukcji zasmiecajacych, procedur to juz mam
> zrobione. Chodzi mi o cos, co sprawi, ze kod bedzie jeszcze bardziej
> trudny do przeanalizowania (bez maszyn wirtualnych bo to osobna
> dzialka).

Kod samomodyfikujący się, jakaś kompresja, kodowanie (nawet głupi xor
z jakąś stałą).  Możesz też stałe zapisywać wprost w segmencie kodu --
disasemblery się pewnie trochę pogubią.

w.

Z tym samomodyfikujacym sie kodem to bym sobie darowal, gdyz kazdy antyvirus 
odrazu okrzyknie ze twoj program to virus/spyware
mimo iz twoj program jest niewinny (tak dziala ta cala heurystyka).
Uwazaj tez na odpowiednie flagi dla kawalka pamieci z pod ktorego chcesz 
wykonywac kod, bo vista jest bardzo restrykcyjna jesli o to chodzi.
(caly mechanizm DEP)

On Wed, 25 Jun 2008 17:09:08 +0200, re-l wrote:

> Z tym samomodyfikujacym sie kodem to bym sobie darowal, gdyz kazdy antyvirus 
> odrazu okrzyknie ze twoj program to virus/spyware
> mimo iz twoj program jest niewinny (tak dziala ta cala heurystyka).

Z tym samomodyfikujacym kodem jest problem, jesli np. jakis fragment zostal
poddany mutacji i zmieniony zostal codeflow, gdzie tu cos modyfikowac
potem? Jest jeszcze kwestia keszowania procesora, po kazdorazowym
nadpisaniu bufora trzeba odczytac bajt z pamieci, zeby mu sie "odetkalo".

> Uwazaj tez na odpowiednie flagi dla kawalka pamieci z pod ktorego chcesz 
> wykonywac kod, bo vista jest bardzo restrykcyjna jesli o to chodzi.
> (caly mechanizm DEP)

DEP jest bardzo restrykcyjny juz od XP SP2 :), wiec o to sie nie martwie.

-- 
Bartosz Wójcik | www.pelock.com

On Tue, 24 Jun 2008 17:47:15 +0200, Wojciech Muła wrote:

> Kod samomodyfikujący się, jakaś kompresja, kodowanie (nawet głupi xor
> z jakąś stałą).  Możesz też stałe zapisywać wprost w segmencie kodu --
> disasemblery się pewnie trochę pogubią.

..akurat nie o to mi chodzi, bardziej by mi zalezalo na jakichs ciekawych
pomyslach co do mutacji samego kodu (a nie jego szyfrowania np.
polimorficznymi algosami)

-- 
Bartosz Wójcik | www.pelock.com

ale co chcesz mutowac, odpalasz exeka, on sie mutuje i zapisje na dysku w 
innej postaci ?
czy exek laduje sie do pamieci, a potem mutuje swoj 'segment kodu' ?
i niby jak by to mialo ochronic przed reverse-engineringiem.

triki w stylu 'zmien cos 100 rozkazow dalej, bo jeszcze nie jest w code 
cache'u' owszem spowoduja
ze debugger/disassembler beda widzialy co innego niz to co sie obecnie 
naprawde wykonuje ale sa
bardzo ryzykowne na obecnej architekturze wielordzeniowej, bo tak naprawde 
nie wiesz, czy to
100 rozkazow dalej bedzie wykonywal jeszcze ten sam rdzen, jaki jest rozmiar 
code cache'a itp. itd.
i czy na procku ktory wyjdzie za 2 lata to jeszcze bedzie dzialalo.

... oczywiscie to 100 rozkazow to tak z palca wyssane :) 

On Fri, 27 Jun 2008 09:05:21 +0200, re-l wrote:

> ale co chcesz mutowac, odpalasz exeka, on sie mutuje i zapisje na dysku w 
> innej postaci ?
> czy exek laduje sie do pamieci, a potem mutuje swoj 'segment kodu' ?
> i niby jak by to mialo ochronic przed reverse-engineringiem.

...kod, np. kod jakiejs procedury jednej wybranej :)

co do reversingu, to czy widziales kiedys zmutowany kod?

> triki w stylu 'zmien cos 100 rozkazow dalej, bo jeszcze nie jest w code 
> cache'u' owszem spowoduja ze debugger/disassembler beda widzialy co innego niz to co sie obecnie 
> naprawde wykonuje ale sa bardzo ryzykowne na obecnej architekturze wielordzeniowej,
> bo tak naprawde nie wiesz, czy to 100 rozkazow dalej bedzie wykonywal jeszcze ten sam
> rdzen, jaki jest rozmiar code cache'a itp. itd. i czy na procku ktory wyjdzie za 2 lata to
> jeszcze bedzie dzialalo. oczywiscie to 100 rozkazow to tak z palca wyssane :)

dlatego napisalem, ze trzeba odczytac nadpisany kod (wystarczy 1 bajt), tak
sie obecnie robi przy samomodyfikujacym kodzie, ale samomodyfikujacy kod
mnie nie interesuje.

-- 
Bartosz Wójcik | www.pelock.com

Bartosz Wójcik <antispam@dont.use.it> wrote:

> co do reversingu, to czy widziales kiedys zmutowany kod?

Z ciekawości: daj jakiś mało rozbudowany przykład kodu
przed i po mutacji.

w.

On Fri, 27 Jun 2008 18:23:28 +0200, Wojciech Muła wrote:

> Z ciekawości: daj jakiś mało rozbudowany przykład kodu
> przed i po mutacji.
> 
> w.

"mov eax, [edx + 4]"

2-krotna mutacja, bez zmiany flow, bez junkow, ogolnie bez niczego
ciekawego

1.

00000000: 33C7                 xor         eax,edi
00000002: B8DBA3FFFF           mov         eax,0FFFFA3DB
00000007: 0FB6C4               movzx       eax,ah
0000000A: 354D807F15           xor         eax,0157F804D
0000000F: 0FBAF0A3             btr         eax,0A3
00000013: 8B84826CFC01AA       mov         eax,[edx][eax]*4[-055FE0394]

2.

00000000: D3D0                 rcl         eax,cl
00000002: B8757F0000           mov         eax,000007F75
00000007: 98                   cwde
00000008: 8D801F817F4E         lea         eax,[eax][04E7F811F]
0000000E: 0D630A4000           or          eax,000400A63
00000013: 8B84020DF53FB1       mov         eax,[edx][eax][-04EC00AF3]

z wieksza grupa instrukcji mozna robic wiecej (np. wymieniac rejestry,
przewidywac wykorzystanie rejestrow w procedurach WinAPI), aha kod nie dba
o flagi (takie bylo zalozenie, zeby za duzo syfu z pushfd nie wyszlo)


-- 
Bartosz Wójcik | www.pelock.com

On Sat, 28 Jun 2008 01:41:03 +0200 Bartosz Wójcik
<antispam@dont.use.it> wrote:

> > Z ciekawości: daj jakiś mało rozbudowany przykład kodu
> > przed i po mutacji.
> > 
> > w.
> 
> "mov eax, [edx + 4]"
> 
> 2-krotna mutacja, bez zmiany flow, bez junkow, ogolnie bez niczego
> ciekawego
> 
> [...]

Można sobie łatwo z tym poradzić --- przekonwertować kod asemblerowy
wprost na C, skompilować z optymalizacją i większość śmieci znika.  Dla
próby przepisałem ręcznie te dwa kawałki i gcc -O3 ładnie wyprowadził
wszystkie stałe.  Przy odrobinie wysiłku można napisać automatyczny
translator asm -> C.

Kod dla drugiego przykładu:
---
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>

int main(int argc, char* argv[]) {
	uint32_t eax, edx, tmp;
	int16_t ax;

	//mov         eax,000007F75
	eax = 0x000007F75;

	//cwde
	ax  = (eax & 0xffff);
	eax = ax;
	
	//lea         eax,[eax][04E7F811F]
	eax += 0x04EC00AF3;

	//or          eax,000400A63
	eax |= 0x000400A63;

	//mov         eax,[edx][eax][-04EC00AF3]
	tmp = eax - 0x04E7F811F;
	// i tutaj odczyt z pamięci, spod adresu edx + tmp
	
	printf("eax = %d, edx = %d, addr = %d\n", eax, edx, tmp);
	return 0;
}
---

To co wyprodukował gcc (przycięte):
---
main:
	leal	4(%esp), %ecx
	andl	$-16, %esp
	pushl	-4(%ecx)
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%ecx
	subl	$20, %esp
	movl	$4262220, 12(%esp)	<--- wyniki
	movl	$0, 8(%esp)		<--- obliczeń
	movl	$1321241195, 4(%esp)	<---
	movl	$.LC0, (%esp)
	call	printf
	addl	$20, %esp
	xorl	%eax, %eax
	popl	%ecx
	popl	%ebp
	leal	-4(%ecx), %esp
	ret
---

w.

On Sat, 28 Jun 2008 12:42:11 +0200, Wojciech Muła wrote:

> Można sobie łatwo z tym poradzić --- przekonwertować kod asemblerowy
> wprost na C, skompilować z optymalizacją i większość śmieci znika.  Dla
> próby przepisałem ręcznie te dwa kawałki i gcc -O3 ładnie wyprowadził
> wszystkie stałe.  Przy odrobinie wysiłku można napisać automatyczny
> translator asm -> C.

no tak, ale miales tylko 1 instrukcje bez dodatkowych utrudnien oraz innych
zaleznosci, jesli chcesz przysle ci jakis "zyciowy" fragment kodu na
pelnych opcjach :)

ale ogolnie wiesz o co mi juz chodzi, szukam dodatkowych mozliwosci mutacji
kodu

-- 
Bartosz Wójcik | www.pelock.com

"re-l" <xxx@spam.no> wrote:

> co do mutacji - mozna by ja rozszezyc o zakres intowych instrukcji sse / mmx
> wtedy mozna dopiero zagmatwane rzeczy robic.

Polecam Bartkowi przyglądnąć się uważniej instrukcji
PSHUFB -- to jest killer. :)

w.

On Mon, 30 Jun 2008 17:15:10 +0200, Wojciech Muła wrote:

> Polecam Bartkowi przyglądnąć się uważniej instrukcji
> PSHUFB -- to jest killer. :)

no i o to mi chodzi od samego poczatku :), jakies przyklady kosmicznych
rzeczy, trudnych do zrozumienia, wiecej prosze :)

-- 
Bartosz Wójcik | www.pelock.com

Bartosz Wójcik <antispam@dont.use.it> wrote:

> On Mon, 30 Jun 2008 17:15:10 +0200, Wojciech Muła wrote:
> 
> > Polecam Bartkowi przyglądnąć się uważniej instrukcji
> > PSHUFB -- to jest killer. :)
> 
> no i o to mi chodzi od samego poczatku :), jakies przyklady kosmicznych
> rzeczy, trudnych do zrozumienia, wiecej prosze :)

Jest jeszcze taki trik -- realizacja BSF za pomocą koprocesora (albo SSE).
Po konwersji int -> float w wykładniku liczby zmiennoprzecinkowej znajduje
się pozycja pierwszego ustawionego bitu:

	fld	uint32
	fstp	[mem64]		; (mem64 >> 52) - 1023 = BSF uint32

Tak BTW ludzie z tego korzystali w czasach, gdy BSF było żałośnie powolne.

w.

Bartosz Wójcik <antispam@dont.use.it> wrote:

> no tak, ale miales tylko 1 instrukcje bez dodatkowych utrudnien oraz innych
> zaleznosci, jesli chcesz przysle ci jakis "zyciowy" fragment kodu na
> pelnych opcjach :)

Jeśli możesz podeślij już zdisasemblowany.  I w żadnym razie nie podawaj
co to wcześniej było. :)  W przyszłą niedzielę się pobawię, bo sam jestem
ciekaw, czy gcc pomoże.

w.

On Mon, 30 Jun 2008 19:26:09 +0200 Wojciech Muła
<wojciech_mula@poczta.null.onet.pl.invalid> wrote:

> Jest jeszcze taki trik -- realizacja BSF za pomocą koprocesora (albo
> SSE). Po konwersji int -> float w wykładniku liczby
> zmiennoprzecinkowej znajduje się pozycja pierwszego ustawionego bitu:

Korzystając z cech liczb zmp. można przesuwać w lewo lub prawo liczby
nawet 52-bitowe (w kodzie 32-bitowy -- 31-bitowe).

Np. masz jakąś 10-bitową stałą, to binarnie będzie: xx_xxxx_xxxx.
Teraz możesz wstawić przed najbardziej znaczącym bitem jedynkę, np. na
pozycji 15: 1000_00xx_xxxx_xxxx.  Po konwersji na liczbę zmp. typu
double (64 bity) masz coś takiego:

	S wwwwwwwwwww 000_00xx_xxxx_xxxx_0..0
	| 11 bitów      52 bity mantysy
	| wykładnika
	bit znaku

Tylko trzeba sobie dobrać tak przesunięcie, żeby jednym nierzucającym
się w oczym MOVem odczytać z pamięci odpowiedni kawałek mantysy. :)

w.

On Mon, 30 Jun 2008 17:51:27 +0200 Bartosz Wójcik
<antispam@dont.use.it> wrote:

> On Mon, 30 Jun 2008 17:15:10 +0200, Wojciech Muła wrote:
> 
> > Polecam Bartkowi przyglądnąć się uważniej instrukcji
> > PSHUFB -- to jest killer. :)
> 
> no i o to mi chodzi od samego poczatku :), jakies przyklady
> kosmicznych rzeczy, trudnych do zrozumienia, wiecej prosze :)

To jeszcze zerknij na PSADBW.

w.

On Mon, 30 Jun 2008 23:10:49 +0200, Wojciech Muła wrote:

> To jeszcze zerknij na PSADBW.

tylko zdajesz sobie sprawe, ze uzywanie SSE3 jest malo realne (a nawet
SSE2) :), moze znasz jakies ciekawe zastosowanie std instrukcji?

-- 
Bartosz Wójcik | www.pelock.com

On Tue, 1 Jul 2008 23:34:04 +0200 Bartosz Wójcik <antispam@dont.use.it>
wrote:

> On Mon, 30 Jun 2008 23:10:49 +0200, Wojciech Muła wrote:
> 
> > To jeszcze zerknij na PSADBW.
> 
> tylko zdajesz sobie sprawe, ze uzywanie SSE3 jest malo realne (a nawet
> SSE2) :),

Sorry, wylazły moje zboczenia. :)

> moze znasz jakies ciekawe zastosowanie std instrukcji? 

Używasz do czegoś BSF lub BSR?  Próbowałeś robić coś z tymi dziwacznymi
instrukcjami do BCD: AAA, DAS, itp.?

w.