ptrace

[Ormi]

Heh, pomysły brzmią ciekawie, kwestia jak by się to sprawdziło w praktyce
A jeśli chodzi o

Czyli ktos chce zmienic kod systemu, nie musi sie przepier**lac przez tony plikow w c

Naprawdę łatwo się tak mówi, ale utrzymanie "porządku" przy kilkunastu milionach linii kodu to rzecz niemożliwa do wykonania. A poza tym (mówię na przykładzie jądra linuxa) tylko początki przeglądania kodu jądra są bardzo trudne Wręcz można się przy tym załamać. Ale po pewnym czasie zaczynasz kapować "o co w tym chodzi", gdzie szukać danych funkcji itp. Do tego bardzo przydatne są programiki w stylu global(czy jakoś tak). Przykład:
http://www.tamacom.com/tour/kernel/linux/
Dzięki temu gdy myslisz sobie: a obejrzę sobie jak działa ładowanie modułów jądra. No to wyszukujesz funkcję sys_init_module. Tam oczywiście mnóstwo wywołań innych, dziwnych funkcji. Dzięki global klikasz po prostu na funkcję do przeglądniecia i jest - nie trzeba grepować całego kodu jądra

[omegalfa]

1) Opanowanie tak prostej funkcji jak ptrace nie powinno byc problemem dla takiego h4x0ra jak Ty.
2) Pomysly odnosnie OS sa plytkie jak kaluza po letniej mzawce.
3) Przestan sie lansic z tym asemblerem. Juz Ci to kiedys powiedziano ale widac dalej nie dotarlo.

Oh, zapomnialbym -- bawi mnie fakt, ze tolerujecie obecnosc czlowieka, ktory podmienil wam sajt. (Tak drogie Panie i drodzy Panowie, esp666 to h3x. Trudno tego nie zauwazyc skoro obaj zawsze pierdola o tym jaki to asembler jest swietny a reszta ssie.)
Proof? https://www.rootkit.com/user.php?name=h3x ale badzmy szczerzy, srednio inteligentny czlowiek juz dawno to skminil.

PS.
Chcialbym jeszcze sprostowac pewien mit. Otoz asembler w dobie aktualnych kompilatorow wcale nie wykazuja sie tak bardzo zwiekszona wydajnoscia. Przeczytajcie sobie troche literatury na ten temat a potem o tym mowcie. (Pomijam przypadek w ktorym zwykly programista asemblera [jednym slowem zaden magik] generuje gorszy kod od aktualnych kompilatorow. A jak myslicie ile *magikow* asma poznaliscie w zyciu? bedzie chociaz jeden?)
Oh ah i kupno nowego, szybszego sprzetu zawsze bedzie tansze niz oplacenie kolejnych 6 miesiecy czasu programisty aby uzyskac wzrost wydajnosci o e.g. 20% (przy czym nowy sprzet podniesie ja o e.g. 40%).

;[