Jak obliczyć/znaleźć adres shellcode -u?

[I_v0]

Zastanawiam się właśnie jak znaleźć adres shellcode w pamięci, kiedyś to było proste (banalne) wystarczyło przed shellcodem dać rampe NOP i zgadnąć adres ktorejs z instrukcji rampy. Teraz trzeba troche potańczyć, lokalnie to nie jest to AŻ tak trudne do zrobienia, np. netric w [1] opisuje procedurę znajdywania adresu shellcode umieszczonego w zmiennej środowiskowej i chociaż jeszcze się wczytuję w ten artykuł to jednak nie da się wykorzystać tej techniki w remote bof, sęk w tym że musimy mieć shellcode np. w $HOME, której zdalnie nie ustawimy. Nie bardzo wiem gdzie zadać to pytanie, wydaje mi się że w newbie ale jeśli gdzie indziej to proszę o przesunięcie tematu.

Pozdrawiam

[1] http://packetstorm.linuxsecurity.com...c/envpaper.pdf

[I_v0]

gwoli wyjaśnienia, metoda opisana w artykule także w żaden sposób nie przybliża nas do pokonania zmiennego EBP. W niej także autor zakłada że znamy adres EBP - którego w isocie nie znamy. Z mojej calonocnej walki z kodem wynika że nie da się tego w żaden sposób wykorzysać.

[gorion]

Podesłałem Ci info na PM.

[MJINKS]

http://www.xsoti.aramin.net/papers/found_ret2.txt

[I_v0]

Tam jest kilka drobnych błedów w tym kodzie który udostępniłeś, ale zrozumiałem o co chodzi, tylko że widzisz... to nadal nie jest to czego tak konkretnie szukam. Widzisz twoje podejście aczkolwiek jest prawidłowe wg. swojego założenia - to jest to kolejny przykład jak wykorzystać błąd lokalnie, mi natomiast chodzi o to żeby błąd wykorzystać zdalnie, mam przed sobą program w którym jest ponad 70 odwołań do funkcji gets() i mogę przepełnić w nim bufor zdalnie tyle że na tym się kończy bo nie umiem wskazać shellcodu. Być może nie zastanawiałem się nad ewentualnymi warjacjami dość długo, ale na razie to nie wiem jak ugryźć temat.
Lokalnie owszem, b. dobra metoda, tylko że zapewne okaże się że zmieniając adres powrotu wg. ułożenia stosu na moim lub twoim komputerze, nie będzie on wskazywał shellcodu na trzecim komputerze, co więcej - może się nawet okazać że exploit nie zadziała lokalnie po zamknięciu (ew. wysypaniu się po ataku) programu i jego ponownego odpaleniu. Na domiar złego każde wysypanie się programu po przeprowadzeniu udanego/(w większości) nieudanego ataku stwarza administratorowi możliwość wykrycia anomalii - przecież programy same się nie wysypują dając Segmentation Fault... (prawde mówiąc jak bym taki komunikat dostał to wypiałbym fizycznie kompa z sieci i przestudiował wszystko co zostało w coredump.

[I_v0]

Czekajcie czekajcie, bo za duża rotacja występuje, wogóle to chodzi cały czas o podesłany przez MJINKSa kod, tyle że doszedł na końcu plik brute.c, robi on to samo co wcześniej w artykule robiliśmy w gdb "ręcznie". Udało mi się uchwycić w sieci artykuł [1], narazie pobieżnie go przejżałem, ale po powrocie zabieram się za czytanie. Obiecałe ojcu że mu pomogę przewieźć siatkę na ogrodzenie, więc życzcie mi szczęścia bo całą noc nie spałem a teraz 150m siatki ogrodzeniowej będę musiał załadować i rozładować...
Myślałem nad brute.c wcześniej, ale zdalnie nie można wstrzyknąć żadnej instrukcji, jedynie można nadpisać EIP toteż nie zaprzątałem sobie głowy.

EDIT: W czasie kiedy pisałem poprzedniego posta MJINKS puścił swojego
EDIT2: [2] http://www.usenix.org/events/sec03/t...ml/dao001.html

[I_v0]

Ok, więc pod adresem [1] znalazłem przegląd możliwości włamań opartych o atak na pamięć, na tej stronie jest przegląd ale cały dokument (4 strony) traktuje o zabezpieczeniu przed tego typu atakami, przeczytawszy sporą część tego dokumentu doszedłem do wniosku że ataki na pamięć wcale się nie chylą się ku końcowi, wciąż istnieją metody przepełnień buforów które da się wykorzystać zdalnie, może po prostu nie jest to już tak proste jak kiedyś. Bardzo ciekawa jest kombinacja ataków nadpisania ciągu formatującego w celu zlokalizowania w pamięci buforu który następnie przepełniamy klasyczną metodą. Spróbuję w najbliższym czasie napisać na przykładzie jak się do tego zabrać.

[1] http://www.usenix.org/events/sec03/t...ml/dao003.html