Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Prośba o spostrzeżenia od profesjonalistów :)
#11
Dzięki wielki za pomoc . Mam nadzieję że kiedyś spotkamy się na defconie ;). Literowa wpadka.. Nawet prezydent może się pomylić :D

Tak się dać chlasnąć zwykłej strzydze. Coś ty ją chciał wychędożyć?
Odpowiedz
#12
(03-15-2017, 21:02)920806 napisał(a): Dzięki wielki za pomoc . Mam nadzieję że kiedyś spotkamy się na defconie ;). Literowa wpadka.. Nawet prezydent może się pomylić :D

Mocna obsada polskich teamów ctf już tam siedzi - ale jak dobrze pójdzie to faktycznie się spotkamy :D 

ProTip: jak uczysz się programowania, rób swoje własne projekty. To uczy chyba najbardziej.
 Gdyby Java miała prawdziwy garbage collector to programy kasowałyby się podczas uruchomienia.

Odpowiedz
#13
Dzień dobry ,

Nudny niedzielny dzień ..a po głowie chodzą myśli i pytania :)!

Zbudowałem swoją własną definicje inzynierii wstecznej ,jeśli się mylę przyjmę kazdą uwagę.

"Inzynieria wsteczna, polega na analizie kodu INSTRUKCJI dla procesora,która powstała w wyniku kompilacji kodu programu pisanego np.w C++ ,C, C# ?":)
link do filmu który mnie zainspirował:
Kod:
https://www.youtube.com/watch?v=VroEiMOJPm8&index=6&list=PLhixgUqwRTjxglIswKp9mpkfPNfHkzyeN

Teraz niewiadoma:

1. Gdy używa się języków nie kompilowanych , a interpretowanych np. Python/JS jak odnaleźć kod takiej instrukcji ?.
Czy jedną z dróg może być debbuger wbudowany w Chrome,Firefox?.
Moje spostrzeżenie: Skoro przeglądarki umożliwiają wgląd do kodu to czy to była by jedna z metod?Tyczy się to głównie Js, ale co np. z Pythonem który jest wykorzystywany w technologiach webowych ?

Tu się nasuwa kolejna niewiadoma .. Co z językami skryptowymi ?:P PHP/CGI/JS

Cytat:Program w języku interpretowanym nie jest kompilowany, lecz jest przechowywany w postaci kodu źródłowego i dopiero podczas uruchomienia wczytywany, interpretowany i wykonywany przez interpreter języka.
By Wikipedia(...)

Ciekawi mnie sam sposób "dobrania" się do miejsca gdzie jest interpretowany,ale tez do samego zasobu ze skryptem.Czy możne to uzyskać np. przez Inżynierię wsteczną ?

Generalnie w internecie wygląda to fajnie , osoba na filmie otwiera program w debuggerze i już.



Rozwazam zakup tych dwóch pozycji:
1.http://helion.pl/ksiazki/asembler-leksykon-kieszonkowy-dawid-farbaniec,asemlk.htm#format/e
2.http://helion.pl/ksiazki/asembler-dla-procesorow-arm-podrecznik-programisty-william-hohl,asarpp.htm#format/e

Spotkałem się w internecie z komentarzem że przy nauce asemblera wystarczy sam leksykon kieszonkowy. Czy olać helion, i np. poszukać coś z wersji anglojęzycznej i wydawnictwa O'reilly :) (chce zasięgnąć tylko opinii)

Tak się dać chlasnąć zwykłej strzydze. Coś ty ją chciał wychędożyć?
Odpowiedz
#14
Zbudowałem swoją własną definicje inzynierii wstecznej ,jeśli się mylę przyjmę kazdą uwagę.


Definicja jak definicja, jeśli według Ciebie jest poprawna i się sprawdzi to kto wie. Może za x lat, na uczelniach zaraz po architekturze Von Neumana będą uczyć o inżynierii wstecznej według 920806 (data urodzin? :) ). Pytanie po co komplikować sobie sprawę i wszystko formalizować. ANSI, ISO i RFC (co stanowi "filar" formalizacji informatyki) są wystarczająco opasłe. 


Inżynieria wsteczna, to dziedzina jak pisałem obszerna. Stosowana przez człowieka od lat. Znów przykład z rękawa: badanie technologii konkurencji czy chociażby walka wywiadów i RE enigmy dokonana przez Polaków we wczesnych latach 30. Co za tym idzie, pojęcie RE w informatyce też jest znacznie szersze niż operowanie opcodami assembly i ja osobiście bym się do tego nie ograniczał i nie zmniejszał kontekstu do języków kompilowanych (lub assemblowalnych). Rewersować można wszystko, protokoły, hardware, software. Główną zasadą, esencją hackingu jest zrozumienie jak działa dana technologia w celu jej skopiowania, exploitowania lub zabezpieczania (co pociąga za sobą exploitację). Ale ja zajmuję się security a nie tworzeniem definicji czy standardów, dlatego koniec dygresji. 

Python nie jest dobrym przykładem, bo jest kompilowany do bytecode (*.pyc). Dostarcza narzędzia jak dis do inżynierii wstecznej.

Idąc dalej, rozmawiamy o poziomie niskim (bytecode), bliskim hardware. To najniższy layer (chyba, że ktoś lubi zabawę technologiami cmos, to wtedy wejdziemy w hardware hacking), za który odpowiadają programiści. Trudno tak przejść od razu do aplikacji webowych. Nie wszystko da się "zrewersować w debuggerze" i tutaj przychodzi wiedza o działaniu poszczególnych warstw systemu. Aby zająć się rewersowaniem czegokolwiek, załóżmy napisanego w języku C, powinno się znać przynajmniej szerokie podstawy języka C i wiedzieć "jak działa komputer". I nie, na dzisiejszych architekturach nie jest to takie trywialne. Ba, zmiana x86 na avr również będzie zaskoczeniem z powodu np. zastosowania arch. Harwardzkiej. Za bardzo przeskakujesz i próbujesz ogarnąć wszystko na raz. Nikt Ci oczywiście nie broni, ale moim skromnym zdaniem lepiej zacząć od podstaw czyli języka C/C++. Żeby coś zepsuć, trzeba wiedzieć jak działa, dlatego biegłe programowanie, znajomość funkcji systemowych (api systemowego) jest niezbędne. Języki stosunkowo trywialne jak ruby, js czy python są proste dla użytkownika z racji zimplementowanego api. Niestety "magia" działająca za tym api nie jest już taka prosta i przyjemna, dlatego potrzeba mieć trochę podstaw. Dalej, żeby poznać dany język trzeba w nim pisać. Z którymś z kolei przychodzi to już bardzo prosto. 

Wikipedia to dobre miejsce na start poszukiwań ale nie należy na niej kończyć a informacje NALEŻY weryfikować ;)

Nie jestem nauczycielem i pewnie się na niego nie nadaję. Polecam jednak uczyć się z dokumentacji (tak czasami jest to trudne i bolesne) oraz dostępnych w sieci materiałów. Kupno książek a tym bardziej "leksykonów", to IMO beznadziejny pomysł. Samo czytanie niczego też Cię nie nauczy. Najlepiej pisać i rozwiązywać problemy. Ale to już wiesz. Książki się szybko dezaktualizują a wiedza w nich dostępna nie jest tajemna za to obecna w wielu postaciach i wersjach w sieci.
Dwa, dobór pozycji sugeruje, że chyba nie do końca jesteś zdecydowany albo nie robiłeś aż tak wnikliwego researchu. Ależ mi wyszedł retoryczny ton. ARM jest RISC a x86 CISC. Niby RISC to mniej operacji = łatwiejsza nauka, z drugiej strony opkodów pamięta się kilkadziesiąt, resztę się sprawdza w dokumentacji. Natomiast pisanie na CISC to możliwość pozwolenia sobie na luksusy i wykonanie bardziej złożonych operacji jednym rozkazem. Zaczynałbym od assembly pod x86. Późniejsze przestawienie się będzie łatwiejsze. 

Co do tego, jak wygląda to w internecie. Live overflow ma fajny kanał, gdzie prezentuje zagadnienia z CTF. Akurat przykład przytoczony przez Ciebie jest delikatnie mówiąc trywialny i takich błędów się nie spotyka. Zadania ctf za 50 punktów często będą dużo trudniejsze. Natomiast jeśli uważasz, że to "wrzucić w debugger i już" to zazdroszczę optymizmu. Czasami kompilatory optymalizują kod w taki sposób, że staje się on bardzo mało zrozumiały dla człowieka, co dopiero jego eksploitacji. Potem dochodzą różne mechanizmy obrony jak zaciemnianie kodu (tak, można to też zrobić w językach jak python), obrona przed podłączeniem debuggera (to akurat nie jest hardcore) czy szyfrowanie i pakowanie aplikacji. RE się rozwija, tak samo rozwijają się zabezpieczenia przed nią. Wykorzystanie RE w celu odtworzenia oprogramowania, którego wsparcie już się zakończyło, a kod nie był specjalnie chroniony jest nie lada wyzwaniem, szkoda wspominać co się dzieje, gdy ktoś umyślnie zabezpieczył swój program przed takim działaniem. Wszystko da się złamać, potrzeba "tylko" wiedzy i czasu. Są rozwiązania na rynku, które dały dużo czasu ale wciąż nie poległy. A to tylko "binarki".

Reasumując, zrozumienie działania komputera i dogłębna nauka programowania (a nie klepania kodu), odpowie na wszystkie Twoje pytania postawione w poście. Niestety nie odpowiem Ci na nie wprost, bo napisano o tym wiele papierków, książek, exploitów i wciąż nie wyczerpano tematu, więc zbyteczna byłaby moja próba zrobienia tego tutaj w poście. Bo ani nie wyszło by lepiej, ani szybciej. Cierpliwości życzę i powodzenia. Staraj się rozgryzać zagadnienia powoli, po kolei - jeśli na etapie realizacji czegokolwiek pojawią się pytania, myślę że forum chętnie Ci pomoże.

Edit. Znów mi ściana tekstu wyszła... eh.

Edit2.
Jak już pisałem o tych językach jak python, implementowane "gotowce" zawierają błędy, podatności. Złe zastosowanie określonych modułów czy ufanie rozwiązaniom jak pythonowy sandboks nie jest dobrym pomysłem. I haker powinien wiedzieć, jak ten zły pomysł przekuć na wykonanie kodu i shella na serwerze. Następnie warto zaznajomić się z tematem, jak uniemożliwić takie akcje, aby w raporcie zasugerować sysopsom co jest do poprawy.
 Gdyby Java miała prawdziwy garbage collector to programy kasowałyby się podczas uruchomienia.

Odpowiedz


Podobne wątki
Wątek: Autor Odpowiedzi: Wyświetleń: Ostatni post
Thumbs Up Prośba w nakierowaniu PrOmil1233 4 637 12-13-2014, 16:46
Ostatni post: Heron

Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości
stat4u