Mam opis pod Windows (a jak będzie pod Linuksem?)
http://www.codeproject.com/Articles/189711/Write-you
r-own-Debugger-to-handle-Breakpoints
http://www.codeproject.com/Articles/43682/Writing-a-
basic-Windows-debugger

Tam jest nietypowo, bo pułapkę ustawia proces śledzony, ale doszedłem że
można użyć WriteProcessMemory. Nawet gdy nie ustawię pułapki, debugger
zatrzymuje się na samym początku wykonywania programu w
ntdll.DbgBreakPoint (czy zawsze tak jest)?
Aby otrzymac adres początku programu muszę znać ramki stosu, jak można
wylistować je?

do góry

W dniu środa, 1 maja 2013 21:48:39 UTC+2 użytkownik Borneq napisał:
> Mam opis pod Windows (a jak będzie pod Linuksem?)
>
> http://www.codeproject.com/Articles/189711/Write-you
r-own-Debugger-to-handle-Breakpoints
>
> http://www.codeproject.com/Articles/43682/Writing-a-
basic-Windows-debugger
>
>
>
> Tam jest nietypowo, bo pułapkę ustawia proces śledzony, ale doszedłem że
>
> można użyć WriteProcessMemory. Nawet gdy nie ustawię pułapki, debugger
>
> zatrzymuje się na samym początku wykonywania programu w
>
> ntdll.DbgBreakPoint (czy zawsze tak jest)?
>
> Aby otrzymac adres początku programu muszę znać ramki stosu, jak można
>
> wylistować je?


dobre pytanie, nie wiem dokladnie,
ale prawdopodobnie (w 32bitowej wersji)
jest tak ze w ebp masz wskaznik na poczatek
tramki stosu danej funkcji, pod ktorym to adresem
jest zapisany poprzedni ebp w ten sposob przez
wyluskiwanie mozna sie cofnac, jesli main
by nadal ebp wartosc 0 to mozna sprawdzic kiedy
koniec cofania (ale nie wiem czy tak jest)

Przed kazdym z tych adresow na stosie sa adresy
powrotów dla ret - nie sa top adresy poczatku funkcji w sekcji .code tylko adresy tuz
za
call (o ile dobrze to rozumiem) ale cofajac sie
z nich 4 bajty dostaniesz prawdopodobnie
adresy poczatkow procedur kolejnych poziomów

- jest to ew przyblizony obraz ale tak to mw chyba
jest - bo tak sobie to wyobrazam, czyli nie jest to takie skomplikowane

do góry

Użytkownik "Borneq" <b...@a...hidden.pl> napisał w wiadomości
news:klrrio$821$1@node2.news.atman.pl...
> Aby otrzymac adres początku programu muszę znać ramki stosu, jak można
> wylistować je?

Jest coś takiego
http://svn.pld-linux.org/cgi-bin/viewsvn/backtracexx
/

do góry

Użytkownik "firr kenobi" <p...@g...com> napisał w wiadomości
news:44c0cefb-1b95-4137-afc7-d9deb0cd528e@googlegrou
ps.com...
> jest tak ze w ebp masz wskaznik na poczatek
> tramki stosu danej funkcji, pod ktorym to adresem

Dzięki za info, mam nadzieję że większość programów używa ebp w standardowy
sposób, bo może być jakis program który wola call i ret ale nie ustawia ebp,

do góry

On 2013-05-01 22:58, Borneq wrote:
> Użytkownik "firr kenobi" <p...@g...com> napisał w wiadomości
> news:44c0cefb-1b95-4137-afc7-d9deb0cd528e@googlegrou
ps.com...
>> jest tak ze w ebp masz wskaznik na poczatek
>> tramki stosu danej funkcji, pod ktorym to adresem
>
> Dzięki za info, mam nadzieję że większość programów używa ebp w
> standardowy sposób, bo może być jakis program który wola call i ret ale
> nie ustawia ebp,
Jest ich wiele. Wystarczy miec wlaczona opcje kompilatora omit frame
pointer. W visualu domyslnie sie wlacza razem z opcjami optymalizacji.

Pozdrawiam

Marek

do góry

Użytkownik "Marek Borowski" <m...@...borowski.com> napisał w wiadomości
news:klt1lq$57f$1@news.task.gda.pl...
> Jest ich wiele. Wystarczy miec wlaczona opcje kompilatora omit frame
> pointer. W visualu domyslnie sie wlacza razem z opcjami optymalizacji.

Czy w takim razie jest jakaś możliwość? Debuggery pokazują, ale nie wiem czy
tylko w tym przypadku, gdy mają informację dla debuggera, a to problem
(format dwarf) złozony.
Jakby przeanalizować backtracexx, można by zobaczyc jak sobie radzi.
Zaimportowałem do githuba:
https://github.com/borneq/backtracexx

Pozdrawiam

do góry

wtedy chyba byloby o wiele trudniej
bo o ile asma dosyc latwo disasembluje
sie w przod to gorzej z disasemblowaniem
go w tyl - trzebaby napisac jakies
bardziej skomplikowane algorytmy ktore
pewie dalyby sie napisac i moze gwaratntowaly
by nawet blisko 100% ppoprawnosc ale
to cyba jednak juz dzialka nieco
powazniejszej analizy

wogole debugowanie na poziomie asma
wydaje mi sie robota raczej dla crackerow
a nie normalnych programistow

mi wogole debugger nie wydaje sie niezbedny
aczkolwiek pewnie czasem moze sie przydac
(jest jeszcze rofiler potencjalnie ciekawe
narzedzie ale nie zaznajomilem sie z zadnym
w wiekszym stopniu - pamietam tylko tego z
xcode)

do góry

W dniu czwartek, 2 maja 2013 19:26:53 UTC+2 użytkownik firr kenobi napisał:

> to gorzej z disasemblowaniem go w tyl
Kazda instrukcja (wraz ze swoimi argumentami) musialaby
zajmowac taka sama ilosc bitow. Gdy N poprzednich bitow
zawiera liczbe X, to nie wiemy czy to jest opcode poprzedniej
instrukcji, czy argument "jeszcze poprzedniej" instrukcji :)


Pozdrawiam

do góry

Dnia Thu, 02 May 2013 15:22:47 -0700 po głębokim namyśle M.M. rzekł:

> W dniu czwartek, 2 maja 2013 19:26:53 UTC+2 użytkownik firr kenobi
> napisał:
>
>> to gorzej z disasemblowaniem go w tyl
> Kazda instrukcja (wraz ze swoimi argumentami) musialaby zajmowac taka
> sama ilosc bitow. Gdy N poprzednich bitow zawiera liczbe X, to nie wiemy
> czy to jest opcode poprzedniej instrukcji, czy argument "jeszcze
> poprzedniej" instrukcji :)

To jeszcze nic. Mając dowolną labelkę może być wiele dróg, jakimi
program do nich doszedł.

Ale prawdopodobnie proces jest możliwy, tyle nie ze 100% skutecznością.
Języki są kompilowane w dość przewidywalny i schematyczny sposób,
dałoby się zrekonstruować zmienne i graf bloków kodu co już byłoby
przydatnym narzędziem. Potem dałoby radę wyeleminować z grafu te
bloki, które logicznie można odrzucić na podstawie stanu zmiennych
i rejestrów - udowadniając, że program nie mógł do nich dojść.
Można dorzucić zachowany stos poniżej SP, aktualny stos, możliwe
wcześniejsze stosy i przebieg pomiędzy funkcjami, a to co wymieniałem
dotyczy jednak bloku kodu jedenj funkcji, dałoby radę też użyć
rejestrów, które są już "dead", lae zachowały ostatnie użycie,
byle nie float - i ma się pikne narzędzie.

Pomimo tego uważam, że to wysiłek poświęcony złej sprawie.

--
Edek

do góry

On 03.05.2013 08:47, Edek wrote:

>
> To jeszcze nic. Mając dowolną labelkę może być wiele dróg, jakimi
> program do nich doszedł.
>
> Ale prawdopodobnie proces jest możliwy,

IDA tak działa - sprawdza program flow i rejestruje adresy skoków (po
skoku musimy być na prawidłowej instrukcji) - w ten sposób z czasem
tworzy graf przepływu sterowania a przy tym ignoruje takie "standardowe"
sztuczki jak skakanie do segmentu danych(który z o dziwo ma +x ;) ), czy
skakanie do EIP+2.

Jest cała szkoła - jak pisać kod tak, żeby debugowanie za pomocą IDY
było możliwie trudne - jedna z ciekawszych sztuczek(przy czym ma już
kilka lat, więc pewnie nauczyli się to obchodzić): umieść na początku
funkcji kilka instrukcji, printf("%s",ESP+xxx), potem skok gdzie
indziej. Skacz do funkcji za pomocą if(!foo) bar(); else (foo+bar)(); -
disassembler pójdzie tylko pierwszą ścieżką bo druga jest osiągalna
tylko w runtime.


--
Pozdrawiam
Michoo

do góry