У меня есть несколько невинных / начинающих вопросов:
- Для чего нужен обратный инжиниринг?
- Как программист, я должен изучить искусство обратного проектирования?
- Каковы преимущества для программиста, который имеет опыт работы с ним?
c
assembly
low-level
reverse-engineering
socksocket
источник
источник
Ответы:
Реверс-инжиниринг в основном хорош для взлома и взлома (удаление защиты с помощью серийного номера или ввода пароля), а также для понимания вирусов или чудес, которые могут выполнять другие программы. Иногда это полезный навык, чтобы найти ошибки в программах, для которых у вас нет исходного кода, и исправить их.
Да, попробуйте выучить ассемблер и использовать приличный отладчик. Это сделает вас лучшим разработчиком, понимая вещи на более низких уровнях, которые ближе к металлу.
Вы будете хорошим хакером / взломщиком. Вы могли бы работать на других производителей антивирусов. В качестве личного примера: однажды я разработал программное обеспечение для отслеживания ошибки, возникшей при установлении соединения оракула. Никто не мог решить проблему, поэтому я получил известность.
Кроме того, я также хотел бы привести комментарий @ johannes , так как он абсолютно прав:
источник
Мне нравится ответ Falcon , но я хотел бы добавить, что в некоторых старых скучных бизнес-приложениях реверс-инжиниринг может избавить вас от неприятных неприятностей.
На работе мы много делаем, когда выполняем интеграцию данных со сторонней системой, которая не имеет никакого нового обслуживания, поэтому мы можем знать, где она должна или не должна ломаться.
Мы также используем реверс-инженера для проверки качества кода (с определенными ограничениями, конечно) на сторонних компонентах, которые мы покупаем, если исходный код не включен.
Моя реальная точка зрения такова: обратный инжиниринг не привязан к какой-либо одной технологии или языку, а представляет собой процесс, в котором вы изучаете внутреннее устройство «черного ящика» . Если у вас есть код, от которого вы зависите, но которому вы не доверяете или которому не можете доверять, вам обязательно стоит заглянуть под капот и посмотреть, что делает этот код.
источник
Есть также офигительно скучная сторона реверс-инжиниринга. Это когда в вашей компании есть немного кода или программы, которая все еще используется, но никто не утверждает, что знает что-либо об этом. Таким образом, вы проходите через это, документируете, пишете тесты и все, что нужно сделать перед началом проекта. Вы делаете это для части программного обеспечения, которая уже написана, следовательно, "обратный инжиниринг".
Намного проще, когда у вас есть код, но это все еще технически реверс-инжиниринг. Это один из тех терминов, которые часто встречаются на деловых встречах, когда они говорят о старых проектах.
источник
Просто чтобы расширить бизнес-ценность реверс-инжиниринга - более половины новых клиентов, с которыми мы сталкиваемся, имеют существующую систему / приложение (не всегда в производстве, имейте в виду), но когда отношения с предыдущим поставщиком разработки программного обеспечения достигли цели.
Примерно в 30% случаев заказчик вообще не имеет исходного кода для своей системы, и во многих случаях большая часть реального бизнес-процесса, правил и знаний заключена в коде.
И в нескольких случаях, когда предыдущие поставщики получили злонамеренные действия, запутали двоичные файлы, синхронизировали код и т. Д., Чтобы завладеть клиентом на неопределенный срок.
Таким образом, чтобы ответить на ваш вопрос, обратный инжиниринг часто является отправной точкой для новых взаимодействий с довольно отчаянными (и сожженными) клиентами, и он может быть «критически важным для бизнеса» фактором извлечения забытых знаний из существующего кода.
источник
Я бы сказал, что набор навыков для реверс-инжиниринга и набор навыков для отладки абсолютно одинаковы - если вы фантастический отладчик, вы также фантастический реверс-инженер, и наоборот.
источник
Иногда это используется, чтобы заставить некоторые части / программное обеспечение взаимодействовать, насколько я понимаю. Некоторые странные интерфейсы, ошибки в реализации и т. Д.
Но насколько я понимаю, это очень скользкая тема, и поэтому уже сложные законы разработки программного обеспечения доведены до крайности с помощью обратного инжиниринга.
источник
Что ж, с помощью обратного инжиниринга вы можете повторно использовать код, сводя к минимуму вашу работу. Например, в Symfony2 вы можете конвертировать базу данных, созданную из обычного MySQL, и конвертировать ее в формат доктрины, и это процесс с обратной инженерией, который стал возможен в Symfony. .... и с помощью обратного инжиниринга вы можете увидеть код, скажем, "в 2D"
источник
Я привожу только реальный пример из моего опыта.
Однажды наша компания переняла проект у другой компании. Примерно через полгода в проекте мы поняли, что подпроект был без кода. Когда мы попросили прежнюю компанию предоставить код, они вежливо ответили, что не могут найти код для подпроекта. Нам нужен был код, потому что мы хотели что-то изменить в этом подпроекте.
Я должен был перепроектировать подпроект.
Сначала я декомпилировал сборку (да, это проект .NET). Результатом декомпилированной сборки является простой и запутанный код без имен локальных переменных и сложной структуры управления. Это потому, что компиляция отбрасывает важную информацию, которую нельзя декомпилировать.
Затем я попытался выяснить, где изменить этот код. Чтобы сделать это, я упростил код, чтобы вести себя так же, но более кратко. Я также угадал имена переменных по их поведению. Я много раз перебирал код, пока не понял, что он делает.
Я не перепроектировал все, только ту часть, которую мы должны были изменить. Это было не так уж плохо, около 200 строк кода VB. Это заняло около пяти дней рабочего времени.
источник