У мене є питання невинних / початківців:
Відповіді:
Що таке зворотна інженерія?
Реверсивна інженерія в основному хороша для злому та злому (видаліть захист серійного номера чи підказки пароля), а також для розуміння вірусів чи чудес, які можуть виконувати інші програмні засоби. Іноді це корисна навичка, щоб знайти помилки в програмах, для яких у вас немає джерела, і виправити їх.
Як програміст, чи слід вивчати мистецтво зворотної інженерії?
Так, спробуйте навчитися асемблеру і використовувати гідний налагоджувач. Це зробить вас кращим розробником, розуміючи речі на нижчих рівнях, ближчих до металу.
Якими будуть переваги програміста, який має досвід роботи із зворотною технікою?
Ви будете хорошим хакером / зломщиком. Ви можете працювати з іншими виробниками антивірусів. Як особистий приклад: я одного разу зворотно розробив програмне забезпечення для відстеження помилки, що сталася під час встановлення з'єднання з oracle. Більше ніхто не міг вирішити проблему, тому я отримав деяку популярність.
Крім того, я також хотів би навести коментар @ johannes , оскільки він абсолютно правий:
Я не обмежуся цим «поганим» розтріскуванням. Розбирання може бути корисним, щоб з’ясувати, чи з’їхав компілятор з розуму (однак, як правило, це ваш код), з точки зору більш сидсмена, може бути цікаво побачити, де програма не працює
Мені подобається відповідь Falcon , але я хотів би додати, що в деяких старих нудних світі ділових додатків зворотна інженерія може позбавити вас від деяких неприємних проблем.
На роботі ми робимо це багато, роблячи інтеграцію даних із сторонньою системою, яка не має жодного нового обслуговування, тож ми можемо знати, де вона повинна чи не повинна ламатися.
Ми також використовуємо інженер зворотного зв'язку, щоб перевірити якість коду (звичайно, з певними обмеженнями) на сторонніх компонентах, які ми купуємо, якщо вихідний код не включений.
Моя реальна суть: зворотна інженерія не пов'язана з єдиною технологією чи мовою, а є процесом, коли ви дізнаєтесь про внутрішню «чорну скриньку» . Якщо у вас є код, від якого ви залежите, але ви не вірите чи не можете йому довіряти, вам обов'язково слід заглянути під кришку і подивитися, що робить цей код.
Там також є мертві нудні сторони реверсної техніки. Це коли компанія, в якій ви є, має трохи коду чи програми, які все ще використовуються, але ніхто не стверджує, що про неї нічого не знають. Отже, ви проходите його, документуєте, пишете тести і все те інженерне завдання, яке слід зробити до початку проекту. Ви робите це для вже написаного програмного забезпечення, отже, "зворотної інженерії".
Це набагато простіше, коли у вас є код, але це все ще технічно зворотна інженерія. Це один із тих термінів, який багато спливає на ділових зустрічах, коли вони говорять про застарілі проекти.
Просто для розширення ділової цінності зворотної інженерії - більше половини нових клієнтів, з якими ми стикаємося, мають існуючу систему / додаток (не завжди у виробництві, пам'ятайте), але там, де стосунки з попереднім виробником розробки програмного забезпечення влучили в бік.
Приблизно в 30% випадків клієнт взагалі не отримує джерела для своєї системи, і в багатьох випадках значна частина реального бізнес-процесу, правил та знань зачинена у коді.
І в декількох випадках, коли попередні постачальники отримували звичайну шкідливість, заблукали бінарні файли, заблокували код і т. Д., Щоб затримати клієнта на невизначений термін.
Отже, щоб відповісти на ваше запитання, зворотна інженерія часто є відправною точкою для нових взаємодій з досить відчайдушними (і згорілими) клієнтами, і це може бути «критичним для бізнесу фактором успіху», щоб витягти забуті знання з існуючого коду.
Я заперечую, що набір навичок для реверсивної інженерії та набір навичок для налагодження абсолютно однаковий - якщо ви фантастичний налагоджувач, ви також фантастичний реверс-інженер і навпаки.
Іноді він використовується для отримання частин / програмного забезпечення для взаємодії, наскільки я розумію. Деякі дивні інтерфейси, помилки в реалізації тощо.
Але, наскільки я розумію, це дуже слизька тема, і тому вже складні закони розробки програмного забезпечення з реверсивною інженерією переходять до крайності.
Ну, за допомогою зворотної інженерії ви зможете повторно використовувати код, мінімізуючи свою роботу. Наприклад, в Symfony2 ви можете конвертувати базу даних, зроблену зі звичайного MySQL, і перетворити її у формат доктрини, і це можливий зворотний інженерний процес, який став можливим в Symfony .... і за допомогою зворотної інженерії ви зможете побачити код, скажімо, "у 2D"
Я наводжу лише справжній приклад зі свого досвіду.
Одного разу наша компанія взяла проект від іншої компанії. Близько півроку проекту ми зрозуміли, що підпроект без коду. Коли ми попросили колишню компанію надати код, вони ввічливо відповіли, що не можуть знайти код підпроекту. Код нам був потрібний, оскільки ми хотіли щось змінити в цьому підпроекті.
Мені довелося реінжинірувати підпроект.
Спочатку я декомпілював збірку (так, це проект .NET). Результатом декомпільованої збірки є м'який та заплутаний код без назв локальних змінних та складної структури управління. Це відбувається тому, що компіляція відкидає важливу інформацію, яку неможливо декомпілювати.
Тоді я спробував розібратися, де змінити цей код. Для цього я впорядкував код, щоб він поводився так само, але більш стисло. Я також здогадався назви змінних з її поведінки. Я багато разів перебирав код, поки не зрозумів, що він робить.
Я не реверсував інженера все, лише частину, яку нам довелося змінити. Це було не дуже погано, близько 200 рядків коду VB. На це пішло близько п’яти днів робочого часу.