Elektroda.pl
Elektroda.pl
X
Tektronix
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Reverse Engineering w praktyce - część 1

ghost666 11 Lut 2017 13:33 8085 17
  • Reverse Engineering w praktyce - część 1
    W zaczynającej się serii artykułów postaramy się omówić proces inżynierii wstecznej routera. Będzie to Huawei HG533. Pierwszy etap tego procesu polegać będzie na analizie urządzenia i poszukiwaniu portów szeregowych, które często pozostawiane są w urządzeniu do debugowania i wsparcia technicznego na etapie projektowania i produkcji.

    Jakkolwiek celem inżynierii wstecznej będzie router to te same zasady zastosować można do dowolnego innego urządzenia z wbudowanym systemem, a jest ich w naszych domach coraz więcej. Wszystkie relatywnie skomplikowane urządzenia: drukarki, kamery IP itp będą miały embeddowany system, najczęściej jakiś Linux. Wiele z nich wyposażone będzie w porty szeregowe, które umożliwią "dobranie się" do systemu i komunikację z nim.

    Poszukiwanie portu szeregowego

    Większość portów UART w urządzeniach komercyjnych ma od 4 do 6 pinów, zazwyczaj położonych blisko jednego z układów scalonych, a czasami nawet opisane są na PCB. Jako że nie są one przewidziane do wykorzystania przez użytkownika w gotowym urządzeniu, zazwyczaj nie ma w nich wlutowanych pinów.

    W analizowanym urządzeniu uwagę przyciągają dwa nieobsadzone złącza (były one puste do momentu, gdy autor artykułu nie przylutował do nich pinów, widocznych na zdjęciu:

    Reverse Engineering w praktyce - część 1


    Analizowany układ wyposażony jest, jak się wydaje, w dwa porty szeregowe - na pokładzie są dwa układy scalone wyposażone w interfejs UART. Po prześledzeniu ich lokalizacji na PCB oraz połączeń ścieżek pomiędzy nimi a głównym procesorem systemu, możemy odnaleźć, który z nich jest podłączony do CPU/SoC - to on najpewniej będzie dla nas najbardziej wartościowy i będzie transferował najciekawsze dane. Spróbujmy się do niego podłączyć i zobaczmy co każdy z portów ma nam do zaoferowania.

    Identyfikacja niewykorzystanych pinów

    Więc mamy dwa rządki pinów, które - na pierwszy rzut oka - mogą nam dać dostęp do portów szeregowych. Pierwszym co musimy zrobić, to sprawdzenie które z pinów tych złącz nie są do niczego podłączone i są, zasadniczo, bezużyteczne. Aby to zrobić stosujemy prostą sztuczkę - prześwietlamy płytkę latarką. Wystarczy że poświecimy na PCB od tyłu i popatrzymy na nią od góry. Wtedy powinniśmy zobaczyć coś takiego:

    Reverse Engineering w praktyce - część 1


    Można wtedy łatwo zidentyfikować czy któraś z warstw PCB ma jakieś połączenie z polem lutowniczym złącza. W przypadku naszej płytki, wygląda to następująco (od lewej):

    * Podłączone do czegoś (widać pojedynczą ścieżkę na godzinie drugiej).
    * Niepodłączony.
    * Podłączony do wylewki lub bardzo grubej ścieżki - z pewnością jest to jeden z pinów zasilania, masy (GND) lub VCC.
    * Podłączony z czterech stron, najpewniej jest to drugi pin zasilania - nie ma żadnych sensownych powodów, aby pin w UARTcie miał podłączenie do czterech różnych ścieżek. Najpewniej jest to więc połączenie z inną warstwą wylewki (z dodaną tzw. termalką, czyli ułożeniem miedzi na laminacie, które pozwala lepiej wlutować się w pin potrzebne jest mniej ciepła do rozgrzania pola - przyp.red.).
    * Kolejny pin do czegoś podłączony.

    Lutowanie złącza do pól dla łatwiejszego dostępu

    Pola lutownicze widoczne na zdjęciu są dwoma portami szeregowymi. Jeśli chcemy się z nimi skontaktować musimy dolutować do nich np. goldpiny, jednakże nie jest to takie proste. Jakkolwiek są one polami dla elementów przewlekanych, to dziurka w PCB wypełniona jest twardym i trudnotopliwym lutowiem, więc ciężko wlutować tam element THT.

    W przypadku pierwszego złącza autor zdecydował się przylutować piny do górnej strony złącza. W przypadku drugiego portu przed lutowaniem postanowił przewiercić malutkim wiertłem pole lutownicze, aby móc umieścić tam element przewlekany. Do tego celu wykorzystany został Dremel (ale nada się każda inna wiertarka szybkoobrotowa - przyp.red.) i bardzo cieniutkie wiertło. Rozwiązanie sprawdziło się doskonale, jak widać na zdjęciu.

    Reverse Engineering w praktyce - część 1


    Identyfikacja poszczególnych pinów i ich funkcji

    W analizowanym routerze mamy zatem dwa porty, a w każdym 4 wykorzystane piny. Nadal nie wiemy, czy porty te są wykorzystane i aktywne, jakim protokołęm komunikuje się system etc. Aby to było możliwie, musimy zidentyfikować funkcyjne porty interfejsu UART.

    Standard tego protokołu identyfikuje 6 rodzajów pinów w złączu:

    * Tx - pin nadawania, łączący się z pinem Rx po naszej stronie.
    * Rx - pin odbioru, łączący się z pinem Tx po naszej stronie.
    * Masę - GND.
    * Zasilanie - VCC.
    * CTS - pin kontroli transmisji.
    * DTR - drugi pin kontroli transmisji.

    Ostatnie dwa piny często są nieużywane i nie są konieczne do transmisji. To co potrzebujemy najbardziej to Tx i Rx.

    Dodatkowo wiemy, że piny Tx i Rx są domyślnie podciągane do zasilania. Za podciągania pinu nadawania odpowiada kontroler interfejsu, co oznacza, że jeśli nie jest on podłączony to napięcie na pinie będzie pływać.

    Musimy zatem zidentyfikować trzy piny; to minimum do zestawienia interfejsu: Masę, Tx oraz Rx.

    Dwa z pinów już udało nam się zidentyfikować jako piny zasilania (VCC i GND) - który jest który łatwo możemy rozpoznać z wykorzystaniem multimetru (na opcji pomiaru ciągłości do innego, znanego punktu masy/zasilania lub na opcji woltomierza mierząc napięcie stałe pomiędzy tymi punktami).

    Aby rozpoznać Rx i Tx korzystamy z powyższych wskazówek. Napięcie na pinie Tx będzie podciągnięte do zasilania przez transmiter w urządzeniu. Napięcie na pinie odbiorczym - Rx - będzie pływać do momentu, w którym do układu podłączymy interfejs od naszej strony.

    Mamy teraz dostatecznie dużo informacji, aby móc rozważać podłączenie interfejsu do systemu. Wykorzystamy w tym celu konwerter USB-UART, który podłączmy do zidentyfikowanych linii Tx, Rx i masy. Nie możemy podłączać pinów losowo, bo może to uszkodzić któreś z urządzeń, więc dobrze zastanówmy się i rozumiejmy co robimy.

    Jeśli chcemy lepiej rozpoznać funkcje pinów, to możemy wykorzystać analizator logiczny lub oscyloskop. Wpinamy go w pin jaki wstępnie zidentyfikowaliśmy jako nadawczy, gdzie powinniśmy zobaczyć tego rodzaju transmisję:

    Reverse Engineering w praktyce - część 1


    Po sprawdzeniu poszczególnych pinów oscyloskopem, wiemy już, że:

    * VCC to 3,3 V względem pinu GND. W naszym przypadku są to piny 2 i 3 odpowiednio.
    * Tx jest tam, gdzie się spodziewaliśmy, dodatkowo widać tam transmisję.
    * Rx jest na ostatnim pinie, jaki jest używany. Napięcie tam oscyluje wokół zera, ponieważ nie podłączyliśmy jeszcze nadajnika z naszej strony.

    Teraz wiemy już na pewno jaki jest rozkład pinów w złączu, co sprawia, że możemy podłączyć już interfejs do komputera. Jednakże musimy odpowiedzieć sobie teraz na kolejne pytanie - jakie są parametry transmisji. Nie musimy się bawić w "zgadnij baudrate", nie mówiąc już innych detalach, jak znak końca linii, kontrola parzystości etc, oczywiście jeśli mamy analizator logiczny z możliwością analizy interfejsów. Wtedy urządzenie od razu pokaże nam jakie dane są poprawne.

    Na zdjęciu poniżej widzimy analizę transmisji dla jednego z ustawień. Widzimy, że w pewnym momencie w transmisji pojawia się ciąg znaków: \n\r\n\rU-Boot 1.1.3 (Aug...) - a to już coś nam mówi, m.in. to, że trafiliśmy w poprawne ustawienia.

    Reverse Engineering w praktyce - część 1


    Jak mamy już pinout i baudrate układu, możemy rozpocząć komunikację z urządzeniem.

    Reverse Engineering w praktyce - część 1


    Podłączanie portu szeregowego

    Teraz jak wiemy już wszystko o układzie od strony sprzętowej, możemy zacząć gadać. Łączymy się z interfejsem w routerze dowolnym mostkiem USB-UART. Tak w przypadku autora wygląda gotowy "do rozmowy" system, wraz z wpiętym oscyloskopem do monitorowania transmisji:

    Reverse Engineering w praktyce - część 1


    Teraz możemy uruchomić terminal na komputerze i popatrzeć co nadaje układ. Podstawowy interfejs UART zaczyna wyrzucać nam całkiem przydatne informacje. Autor do podłączenia się do interfejsu wykorzystał następujące komendy pod Linuksem:

    Reverse Engineering w praktyce - część 1


    Co widzimy podczas ładowania się systemu na routerze? Takie coś:

    Code:
    Please choose operation:
    
       3: Boot system code via Flash (default).
       4: Entr boot command line interface.
     0


    ‘Command line interface’?? No to jesteśmy w domu! Po naciśnięciu 4 dostajemy się do linii komend w bootloaderze systemu operacyjnego linuksa.

    Jeśli naciśniemy 3 to zobaczymy, jak system operacyjny ładuje się, a potem zobaczymy komunikat witający nas w systemie i proszący o zalogowanie się. Jeśli developerzy zadali sobie trochę trudu to mogli zmienić domyślne hasło logowania, ale w tym przypadku tak nie było i możemy zalogować się do systemu (z prawem roota!) wpisując użytkownika admin i hasło admin. W przypadku innych urządzeń dane te mogą być inne, ale często są to domyślne dane, których spis znaleźć można w sieci. Po wpisaniu danych logowania, możemy rozpocząć buszowanie w systemie:

    Code:
    -------------------------------
    
    -----Welcome to ATP Cli------
    -------------------------------

    Login: admin
    Password:    #Password is ‘admin'
    ATP>shell

    BusyBox vv1.9.1 (2013-08-29 11:15:00 CST) built-in shell (ash)
    Enter 'help' for a list of built-in commands.

    # ls
    var   usr   tmp   sbin  proc  mnt   lib   init  etc   dev   bin


    W naszym routerze powłoką jest BusyBox - podobny do normalnego Linuxowego shell, który omówimy dokładniej w kolejnej części. Najważniejsze, że uzyskaliśmy do niego dostęp i mamy uprawnienia roota.

    Kolejne kroku

    Mając dostęp do linii komend BusyBoxa możemy zacząć grzebać w oprogramowaniu. Zależnie od tego jak wszystko zostało w systemie rozwiązane możemu uzyskać dostęp do haseł, o ile są zapisane w pliku tekstowym, certyfikatów TLS, różnych prywatnych API, jeśli nie są one zabezpieczone etc.

    W kolejnej części artykułu skupimy się bardziej na inżynierii wstecznej oprogramowania w systemie routera, tym jakie różne są tryby bootowania OSa na urządzeniu, jak robić zrzuty pamięci etc. Wszystko to możemy zrobić mając tak bezpośredni dostęp do firmware urządzenia.

    Źródło: http://jcjc-dev.com/2016/04/08/reversing-huawei-router-1-find-uart/

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    ghost666 napisał 9303 postów o ocenie 6884, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • Tektronix
  • #2
    Gelip
    Poziom 28  
    Nie podoba mi się sposób z rozwiercaniem otworów. Jeśli PCB jest wielowarstwowa to rozwiercając otwór możesz spowodować iż później przy lutowaniu noga elementu nie zostanie przylutowana do którejś środkowej warstwy PCB i coś może nie działać lub nie działać jak trzeba. Lepszy sposób to podgrzewanie punktu lutownicą kolbową z jednej strony a z drugiej wciskanie wykałaczki drewnianej.
  • Tektronix
  • #3
    ghost666
    Tłumacz Redaktor
    Gelip napisał:
    Nie podoba mi się sposób z rozwiercaniem otworów. Jeśli PCB jest wielowarstwowa to rozwiercając otwór możesz spowodować iż później przy lutowaniu noga elementu nie zostanie przylutowana do którejś środkowej warstwy PCB i coś może nie działać lub nie działać jak trzeba. Lepszy sposób to podgrzewanie punktu lutownicą kolbową z jednej strony a z drugiej wciskanie wykałaczki drewnianej.


    W pełni się z Tobą zgadzam. Dodałbym tylko, że od wykałaczki lepsza jest igła do strzykawki o odpowiedniej grubości. Można też wykorzysta - jeśli ktoś ma - rozlutownicę, czyli taki podgrzewany odsysacz do cyny.
  • #4
    elektryku5
    Poziom 38  
    Podczas zabawy z routerami warto się też zainteresować złączem JTAG, o ile jest obecne w danym urządzeniu.
  • #5
    mailo
    Poziom 26  
    Witam.

    Myślałem, że inżynierka na zad, to coś więcej niż zlokalizowanie gołym okiem portu UART.

    Analiza kodu , głównie i przeważnie....
    Tytuł interesujący, treść na razie oczywiste oczywistości.
    Czekamy na cz. 2.

    Pozdrawiam.
  • #6
    And!
    Admin grupy Projektowanie
    @elektryku5 jaki sprzęt+oprogramowanie polecasz do JTAG dedykowanego do RE, czy istnieje coś uniwersalnego, czy dla każdej rodziny układów należy wyposażyć się w coś dedykowanego?
  • #7
    elektryku5
    Poziom 38  
    Często wystarcza prosty interfejs na port LPT, bawiłem się softem zJTAG, niestety obecnie już chyba nie jest dostępny/rozwijany.
  • #8
    silelis
    Poziom 11  
    Gelip napisał:
    Nie podoba mi się sposób z rozwiercaniem otworów. Jeśli PCB jest wielowarstwowa to rozwiercając otwór możesz spowodować iż później przy lutowaniu noga elementu nie zostanie przylutowana do którejś środkowej warstwy PCB i coś może nie działać lub nie działać jak trzeba. Lepszy sposób to podgrzewanie punktu lutownicą kolbową z jednej strony a z drugiej wciskanie wykałaczki drewnianej.


    Zgadzam się z przedmówcami. Ja wole korzystać z pinów testowych. Zazwyczaj drukuję jakiś uchwyt na drukarce 3D (uniwersalny) i tak podłączam UART.
    Reverse Engineering w praktyce - część 1

    elektryku5 napisał:
    Podczas zabawy z routerami warto się też zainteresować złączem JTAG, o ile jest obecne w danym urządzeniu.

    W starszych routerach jak najbardziej. Sam ostatnio musialem doprowadzić mój WRT54GL do stanu użyteczności, ale nowe już od tego odchodzą z kilku powodów.
    1) Port LPT w nowych komputerach to rzadkość.
    2) Wsparcie LPT w nowych Windowsach to rzadkość (aby skorzystać z UserPort.exe, ostatnio musiałem postawić na wirtualnej maszynie Windows XP).
    3) Bajeczna prędkośc przesyłu danych. :D
  • #9
    szymon122
    Poziom 38  
    silelis napisał:
    ort LPT w nowych komputerach to rzadkość

    Czy taki debugger zadziała na przejściówce USB - LPT?
  • #10
    krisRaba
    Poziom 27  
    Po przeczytaniu cz.1 chwilowo nic bardzo odkrywczego. Liczę, że w kolejnych częściach będzie coś w rodzaju konferencji na TEDx, gdzie pani opowiadała o wyciągnięciu i modyfikacji firmware'u z tamagotchi (czy jak to się pisze (edit. teraz już na pewno dobrze :D)) analizując transmisję szeregową i pod coś tam się podszywając. W każdym razie nie był to download z odblokowanego MCU ;) Musiałbym to odszukać, ale robiło to wrażenie :D

    Póki co, w temacie, tak się tylko zastanawiam, czy to
    - roztargnienie/pośpiech (time to market),
    - brak wiedzy/umiejętności żeby coś zablokować lub wgrywam gotowca
    - brak chęci (nie płacą mi tu tyle, żeby to pozabezpieczać)
    - celowe działania - bawcie się naszymi urządzeniami, jeśli potraficie
    - jeszcze coś innego...
    by zostawiać "otwarte wrota" do systemu, na domyślnych hasłach (!) itp.
    Kłania się tutaj również wspomniany już przez kogoś wątek kamer IP.

    Jak myślicie?
  • #11
    silelis
    Poziom 11  
    szymon122 napisał:
    silelis napisał:
    Port LPT w nowych komputerach to rzadkość

    Czy taki debugger zadziała na przejściówce USB - LPT?


    Ze standardowymi przejściówkami USB-LPT bym uważał. Zazwyczaj funkcjonalność ich sterowników ogranicza się do obsługi starszych drukarek i kas fiskalnych. :D

    Zgłębiałem kiedyś temat i znalazłem bardzo fajny projekt USB2LPT.

    Ostatecznie niestety nie starczyło mi czasu na jego wykonanie i zakupiłem sobie kartę PCI-Express z LPT i RS232. O ile z działania LPT jestem zadowolony to RS232 nie wspierało pełnego standardu i np. nie zadziałał mi programator ISO-JDM czy MultiProg (musiałem na prędce zrobić PICkit2).

    Swoją drogą to fajnie, że powstał ten temat, bo akurat jakiś czas temy udało mi się wygrać wersję developerską routera Linksys WRT3200 i zamierzam właśnie ją się tak pobawić. :D
  • #12
    Gelip
    Poziom 28  
    silelis napisał:
    W starszych routerach jak najbardziej. Sam ostatnio musialem doprowadzić mój WRT54GL do stanu użyteczności, ale nowe już od tego odchodzą z kilku powodów.
    1) Port LPT w nowych komputerach to rzadkość.
    2) Wsparcie LPT w nowych Windowsach to rzadkość (aby skorzystać z UserPort.exe, ostatnio musiałem postawić na wirtualnej maszynie Windows XP).
    3) Bajeczna prędkośc przesyłu danych. :D

    i dlatego do takich rzeczy warto mieć pod ręką - najlepiej jakiś stary Laptop z portami COM i LPT z Windows XP lub nawet Win98 na pokładzie :-)
    Jeśli chodzi o to iż odchodzą od JTAG'a to nie wiem czy faktycznie tak jest ale zawsze zostaje konsola szeregowa. Często bootloader w routerze pozwala na wymianę oprogramowania i do póki nie będziemy ruszać bootloadera to nie potrzeba JTAG'a. A nawet jeśli nie ma JTAG to chyba na upartego można się wpiąć bezpośrednio w punkty na PCB - oczywiście wymaga to dokumentacji chipów i opisu ich pinów. Poza tym można nawet odlutować FLASH'a, zaprogramować zewnętrznym programatorem i wlutować z powrotem - sam tak naprawiałem router: Naprawa routera
    Wprawdzie nie próbowałem użyć portu w Win10 ale jest on ciągle obsługiwany więc nie powinno być tak źle:
    Reverse Engineering w praktyce - część 1
  • #13
    silelis
    Poziom 11  
    Wsparcie jest i na samym początku próbowałem, ale WRTJTAG.exe potrzebuje jeszcze jednego programu, każdorazowo rejestrującego sterownik (nie pamiętam nazwy) i go uruchamiającego. Ten ostatni program nie chciał zadziałać na architekturze 64-bit systemu operacyjnego.
    Tak jak już wcześniej pisałem w chwili obecnej wsparcie LPT i RS232 jest mocno ograniczone do komunikacji z podstawowymi urządzeniami. Jeśli potrzebujesz trochę bardziej wyszukanej kontroli przepływy danych i komunikacji (zaczynasz używać innych linii niż RX/TX) to pozostają Ci stare systemy i komputery lub ostre kombinowanie.
  • #14
    Gelip
    Poziom 28  
    silelis napisał:
    Wsparcie jest i na samym początku próbowałem, ale WRTJTAG.exe potrzebuje jeszcze jednego programu, każdorazowo rejestrującego sterownik (nie pamiętam nazwy) i go uruchamiającego. Ten ostatni program nie chciał zadziałać na architekturze 64-bit systemu operacyjnego.
    Tak jak już wcześniej pisałem w chwili obecnej wsparcie LPT i RS232 jest mocno ograniczone do komunikacji z podstawowymi urządzeniami. Jeśli potrzebujesz trochę bardziej wyszukanej kontroli przepływy danych i komunikacji (zaczynasz używać innych linii niż RX/TX) to pozostają Ci stare systemy i komputery lub ostre kombinowanie.

    Eee, tam - trzeba wiedzieć jakiego sterownika użyć i jak :-) Już nawet na WinXP 32-bit też trzeba odpowiednich sterowników aby mieć pełny dostęp do portu więc to żadna nowość. Sam z powodzeniem używam takich sterowników nawet w wersji 64-bit do programatora Willem czy ostatnio właśnie do zaprogramowania JTAG'iem routera - wszystko działa jak ta lala na wersji 64-bit :-)
  • #15
    willyvmm
    Poziom 27  
    Arduino doskonale się sprawdza jako programowalny programator + interface.
  • #16
    tplewa
    Poziom 38  
    szymon122 napisał:
    silelis napisał:
    ort LPT w nowych komputerach to rzadkość

    Czy taki debugger zadziała na przejściówce USB - LPT?


    Niestety nie, ale nie ma co kombinowac jesli JTAG mozna zrealizowac na wiele innych spodobow. Najprosciej obecnie to chyba uklady FTDI ktore taka funkcjonalnosc nam daja, pozostaje kwstia oprogramowania... W przypadku routerow w stylu WRT54G itp. mamy tam konkretnie do czynienia z interfejsem EJTAG (mikrokontrolery z rdzeniem MIPS). Choc znam przypadki gdzie z ukladu JTAG nie byl wyprowadzony i przy ukladach BGA trzeba czasem bylo sie bawic z wylutem i wyprowadzaniem interfejsu w rozne czasem dziwaczne sposoby. Inna droga to wylutowanie pamieci flash/nand i zabawa w jej analize. Za zwyczaj mamy jakis bootloader, czasami da sie uzyc oryginalny, czasami trzeba go modyfikowac lub napisac wlasny.

    Generalnie nie da sie tego jakos ogarnac w jakies proste artykly bo co uklad to mozna spotkac inne rozwiazanie...

    ---

    Przykladowo jesli chodzi o EJTAG to kiedys pisalem cos takiego do procesorow Broadcom-a stosowanych w modemach kablowych, soft tez powinien dzialac bez problemu (po wpisaniu ukladu do pliku tekstowego) z WRT itp. Jako interfejs uzywal roznych kabli pod LPT oraz kabelka do ARM-ow JTAG-lock-pick znanego tutaj kolegi Freddie Chopin

    ot tutaj jakis filmik obrazujacy dzialanie tego oprogramowania ;)

    Link


    willyvmm napisał:
    Arduino doskonale się sprawdza jako programowalny programator + interface.


    Do jakis prostych rozwiazan typu pamieci EEPROM SPI/I2C itp. tak - ale w innych wypadkach moze to byc wieksze utrudnienie i lepiej korzystac z innych narzedzi. Jakich tego nie da sie okreslic... niestety RE to w duzej mierze tzw. "inwencja tworcza", oraz praca jak to mowia na dlugie zimowe wieczory ;)
  • #17
    keseszel
    Poziom 26  
    Dorzucę kilka swoich słów. Dawno temu w necie było sporo o RE. Dotyczyło się to głównie edycji oprogramowania przy pomocy debugerów. Stosowało się wtedy SoftIce, czy jakoś tak było to nazwane. Później niewiadomo dlaczego temat się rozmył, strony poznikały. Ciekawe czasy. Tu mamy fajny zarys, że w urządzeniach można grzebać i znaleźć coś ciekawego. Co prawda podniosły się zaraz głosy krytyczne- prościzna, etc.. ale nikt nie sugeruje zrobić z TV 55 cali odbiornika do SETI. I jedna ciekawa , fajna rzecz była zasygnalizowana. Stare laptopy. Myślę, że dawniej programy, ich starsze wersje były dokładniej opisane i umożliwiały całkiem interesujące "grzebanie" w sprzęcie. Dziś większość programów grzebaczowych ;-) jest płatna bądź trzeba należeć do jakiegoś kółka wzajemnej adoracji. Oczywiście podniosą się głosy hejtu, że nic odkrywczego nie wniosłem, ale wg mnie fajnie jest prześledzić ukryte funkcje bądź możliwości w standardowym sprzęcie.
  • #18
    tplewa
    Poziom 38  
    keseszel napisał:
    Dorzucę kilka swoich słów. Dawno temu w necie było sporo o RE. Dotyczyło się to głównie edycji oprogramowania przy pomocy debugerów. Stosowało się wtedy SoftIce, czy jakoś tak było to nazwane. Później niewiadomo dlaczego temat się rozmył, strony poznikały. Ciekawe czasy.


    Niestety to nie jest od dzisiaj :) Juz na poczatku 2000r mozna bylo zaobserwowac cos takiego. Niestety ludzie staja sie coraz bardziej leniwi, na uczelniach nie mam pojecia co wykladaja (jeszcze jak prowadzilem rozmowy kwalifikacyjne w firmie bylem przerazony) itd.

    Obecnie coraz czesciej slysze ze C/C++ to dretwe jezyki (lepsza Java/C# itd. gdzie ma sie wszystko za zwyczaj rozwiazane)... o ASM nie bede juz wspominal :) Ludzia brakuje checi poznania i zainteresowan choc obecnie niemal wszystko podane jest na tacy (kiedys zdobycie jakiejkolwiek informacji graniczylo z cudem i kosztowalo wiele pracy). Sa owszem osoby ktore robia fajne rzeczy - ale niestety jest tego coraz mniej...

    Co nie zmienia faktu ze jak ktos chce to moze bawic sie w RE, takie zabawy poza modyfikacja czegokolwiek maja ogromna zalete edukacyjna. Mozna sie nauczyc tego czego nie dowiemy sie w szkole czy na jakimkolwiek kursie - tylko troche checi potrzeba by posiedziec zamiast isc na piwo ;)

    Z drugiej strony jak zaczniesz prowadzic strone zakonczy sie to mnustwem pytan o kazda pierdołe (najlepiej kazdego poprowadzic za reke), ot jak to mowia chwile pomyslec lub poszukac w google boli ;) Wiec po co sobie robic problemy :)

    Smutne jest chyba to ze obecnie RE najbardziej kwitnie w przestepczosci (zlodzieje samochodow itp.)...