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

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?

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

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.

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.

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.

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.

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.

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”

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.