Inżynieria odwrotna: do czego jest naprawdę dobra? [Zamknięte]

15

Mam kilka niewinnych / początkujących pytań:

  • Do czego służy inżynieria odwrotna?
  • Czy jako programista powinienem nauczyć się sztuki inżynierii odwrotnej?
  • Jakie są korzyści dla doświadczonego programisty?
skarpeta
źródło
5
Czy jest to kwestia wyłącznie o demontażu rodzaju inżynierii wstecznej lub innych, jak również? (ponieważ „montaż” i „niski poziom” są w tagach ..)
Izkata

Odpowiedzi:

14

Do czego służy inżynieria odwrotna?

Inżynieria odwrotna jest dobra przede wszystkim do łamania i hakowania (usuń ochronę numeru seryjnego lub monitów o hasło), ale także do zrozumienia wirusów lub cudów, które mogą wykonywać inne programy. Czasami przydatna jest umiejętność znajdowania błędów w programach, dla których nie masz źródła i ich łatania.

Czy jako programista powinienem nauczyć się sztuki inżynierii odwrotnej?

Tak, spróbuj nauczyć się asemblera i używać porządnego debuggera. Uczyni cię lepszym programistą dzięki zrozumieniu rzeczy na niższych poziomach, które są bliżej metalu.

Jakie będą korzyści programisty, który ma duże doświadczenie w inżynierii odwrotnej?

Będziesz dobrym hakerem / crackerem. Możesz pracować dla innych producentów antywirusowych. Jako osobisty przykład: kiedyś stworzyłem oprogramowanie, aby wyśledzić błąd, który wystąpił podczas nawiązywania połączenia z Oracle. Nikt inny nie mógł rozwiązać problemu, więc zyskałem sławę.

Ponadto chciałbym zacytować komentarz @ johannes , ponieważ ma absolutną rację:

Nie ograniczę się do „złego” pękania. Dezasemblacja może być przydatna, aby dowiedzieć się, czy kompilator oszalał (zwykle jest to jednak twój kod), z bardziej sysadminowego punktu widzenia, interesujące może być sprawdzenie, gdzie zawodzi aplikacja

Sokół
źródło
8
Nie ograniczę się do „złego” pękania. Demontaż może być przydatne, aby dowiedzieć się, czy kompilator oszalał (zwykle jest to kod, chociaż), z bardziej punkcie sysadmin widzenia może to być interesujące zobaczyć, gdzie aplikacja nie ...
Johannes
@johannes: Tak, masz rację. Czy mogę to napisać w mojej odpowiedzi?
Falcon,
jasne, rób co chcesz, nie rości sobie żadnych praw autorskich ;-)
johannes
7
Przepraszam, ale to jest absolutnie okropna odpowiedź. Odwrotna inżynieria absolutnie nie jest „głównie przeznaczona do… łamania i hakowania”, jak zdefiniowano, a każdemu, kto nie zajmuje się programowaniem systemów, szkodzi, jeśli zostanie się do tego wprowadzonym z tej ideologicznej perspektywy.
Chuu,
1
Nie sądzę, aby o tym wspominano, ale bądź ostrożny, jeśli robisz to na oprogramowaniu, które nie jest twoje (lub nikomu nie mówisz). Prawie wszystkie komercyjne umowy EULA zabraniają inżynierii wstecznej. Nie chcesz dostać listu o zaprzestaniu działalności i rezygnacji z kopii do czyjegoś prawnika ds. Własności intelektualnej.
Bratch,
25

Podoba mi się odpowiedź Falcona , ale chciałbym dodać, że w starym nudnym świecie aplikacji biznesowych inżynieria odwrotna może wydostać się z nieprzyjemnych problemów.

W pracy robimy to często, integrując dane z systemem zewnętrznym, który nie wymaga żadnej nowej konserwacji, dzięki czemu możemy wiedzieć, gdzie powinien się on zepsuć, czy nie.

Używamy również inżynierii wstecznej do sprawdzania jakości kodu (z pewnymi ograniczeniami, oczywiście) na kupowanych przez nas komponentach innych producentów, jeśli kod źródłowy nie jest uwzględniony.

Chodzi mi o to: inżynieria odwrotna nie jest związana z żadną technologią ani językiem, ale jest procesem, w którym uczysz się wewnętrznych elementów „czarnej skrzynki” . Jeśli masz kod, na którym polegasz, ale któremu nie ufasz lub nie możesz mu zaufać, zdecydowanie powinieneś zajrzeć pod maską i zobaczyć, co robi ten kod.

Machado
źródło
Heck, nawet przyglądamy się procedurom SQL przechowywanym w wynajętych przez nas systemach innych firm, aby sprawdzić, czy czasami prawidłowo spełniają nasze wymagania.
Machado
3
+1. Nawet najlepiej sprzedający się produkt programowy dużej firmy może być czasem czarną skrzynką, co przy nieodpowiedniej, nieaktualnej, po prostu błędnej, czasem nieistniejącej dokumentacji online i tym podobnych.
RalphChapin
13

Istnieje również nudna, nudna strona inżynierii odwrotnej. Wtedy firma, w której jesteś, ma trochę kodu lub programu, który jest nadal używany, ale nikt nie twierdzi, że nic o tym nie wie. Więc przechodzisz przez to, dokumentujesz, piszesz testy i wszystko to, co inżynierskie powinno być zrobione przed rozpoczęciem projektu. Robisz to dla napisanego już oprogramowania, stąd „inżynieria wsteczna”.

Jest o wiele łatwiej, gdy masz kod, ale nadal technicznie jest to inżynieria odwrotna. To jeden z tych terminów, który często pojawia się na spotkaniach biznesowych, gdy rozmawiają o starszych projektach.

Philip
źródło
+1, szczególnie dla mnie prawdziwe. Pracowałem w niektórych bankach, w których starsze systemy nie miały ani jednego dokumentu technicznego.
Machado
7

Aby rozwinąć wartość biznesową inżynierii odwrotnej - ponad połowa nowych klientów, z którymi się spotykamy, ma istniejący system / aplikację (nie zawsze w produkcji, pamiętajcie o tym), ale tam, gdzie relacje z poprzednim dostawcą oprogramowania doszły do ​​skutku.

W około 30% przypadków klient nie ma w ogóle źródła swojego systemu, aw wielu przypadkach znaczna część prawdziwego procesu biznesowego, zasad i wiedzy jest zamknięta w kodzie.

A w kilku przypadkach, gdy poprzedni dostawcy stali się złośliwi, zaciemnili pliki binarne, zablokowali kod itp., Aby usidlić klienta na czas nieokreślony.

Aby odpowiedzieć na twoje pytanie, inżynieria odwrotna jest często punktem wyjścia do nowych kontaktów z raczej zdesperowanymi (i spalonymi) klientami i może być czynnikiem decydującym o sukcesie biznesowym w celu wydobycia zapomnianej wiedzy z istniejącego kodu.

StuartLC
źródło
2

Twierdziłbym, że zestaw umiejętności do inżynierii wstecznej i zestaw umiejętności do debugowania są dokładnie takie same - jeśli jesteś fantastycznym debuggerem, jesteś również fantastycznym inżynierem wstecznym i odwrotnie.

BlueRaja - Danny Pflughoeft
źródło
1

Czasami służy do tego, aby niektóre części / oprogramowanie współdziałały, o ile rozumiem. Niektóre dziwne interfejsy, błędy we wdrażaniu itp.

Ale z tego, co rozumiem, jest to bardzo śliski temat, a zatem i tak już skomplikowane prawa tworzenia oprogramowania zostały doprowadzone do skrajności dzięki inżynierii odwrotnej.

Koder
źródło
1

Cóż, dzięki inżynierii odwrotnej możesz ponownie wykorzystać kod minimalizując pracę. Na przykład w Symfony2 możesz przekonwertować bazę danych utworzoną z normalnego MySQL i przekonwertować ją na format doktryny, a jest to proces inżynierii wstecznej możliwy w Symfony .... a dzięki inżynierii odwrotnej możesz zobaczyć kod powiedzmy „w 2D”

wanjiku
źródło
0

Z mojego doświadczenia podam tylko przykład ze świata rzeczywistego.

Kiedyś nasza firma przejęła projekt od innej firmy. Około pół roku po projekcie zdaliśmy sobie sprawę, że podprojekt nie zawiera kodu. Gdy poprosiliśmy poprzednią firmę o dostarczenie kodu, uprzejmie odpowiedział, że nie może znaleźć kodu dla podprojektu. Potrzebowaliśmy kodu, ponieważ chcieliśmy coś zmienić w tym podprojekcie.

Musiałem inżynierii wstecznej podprojektu.

Najpierw zdekompilowałem zestaw (tak, jest to projekt .NET). Rezultatem zdekompilowanego zestawu jest nijaki i mylący kod bez nazw zmiennych lokalnych i skomplikowanej struktury kontrolnej. Jest tak, ponieważ kompilacja odrzuca ważne informacje, których nie można dekompilować.

Potem próbowałem dowiedzieć się, gdzie zmienić ten kod. Aby to zrobić, usprawniłem kod, aby zachowywał się tak samo, ale w bardziej zwięzły sposób. Odgadłem też nazwy zmiennych na podstawie jego zachowania. Przeszukałem kod wiele razy, aż zorientowałem się, co on robi.

Nie odtworzyłem wszystkiego, tylko część, którą musieliśmy zmienić. Nie było tak źle, około 200 linii kodu VB. Zajęło to około pięciu dni czasu pracy.

dokładnie
źródło