Я спрашиваю себя , где используется обратная инженерия. Мне интересно узнать это. Но я не знаю, могу ли я/должен поместить это в мое резюме.
Я не хочу, чтобы мой новый начальник думал, что я злой Хакер или что-то в этом роде.:)
Обратное проектирование обычно используется для расшифровки форматов файлов для улучшения взаимодействия. Например, многие популярные коммерческие приложения Windows не работают в Linux, что требует обратной разработки файлов, созданных этими приложениями, чтобы их можно было использовать в Linux. Хорошим примером этого могут быть различные форматы, поддерживаемые Gimp, OpenOffice, Inkscape и т.д.
Другим распространенным применением обратной инженерии является расшифровка протоколов. Хорошие примеры включают Samba, поддержка DAAP во многих -iTunes, межплатформенные IM-клиенты, такие как Pidgin и т.д. Для обратной обработки протокола общие инструменты торговли включают Wireshark и libpcap.
Несомненно, обратная инженерия часто связана с растрескиванием программного обеспечения, что в первую очередь заключается в понимании разборки программ. Я не могу сказать, что мне когда-либо приходилось разбирать программу, отличную от чистого любопытства, или заставить ее делать что-то не так. Одной из плюсов для обратных инженерных программ является то, что, чтобы понять это, вам нужно будет научиться программированию сборки. Однако существуют законные способы оттачивания навыков разборки, в частности, с помощью Crackmes. Важно отметить, что когда вы разрабатываете меры безопасности в своих приложениях или работаете в этом бизнесе, вам нужно знать, как работают обратные инженеры, чтобы попытаться остаться на шаг впереди,
ИМХО, обратная инженерия - очень мощный и полезный навык. Не говоря уже, это обычно весело и захватывающе. Как упоминается hmemcpy, я не уверен, что буду использовать термин "обратное проектирование" в своем резюме, только связанные с ним навыки/знания.
Одно из полей, на мой взгляд, где полезными обратными инженерными навыками могут быть полезны, например, антивирусная индустрия. Тем не менее, я не буду размещать "обратное проектирование" в своем резюме, но я бы записал опыт на языке Ассамблеи, используя разные дизассемблеры/отладчики (такие как IDA, SoftIce или OllyDbg) и другие соответствующие навыки.
Обратное проектирование - это обычно то, что вы делаете, потому что вам нужно, а не потому, что вы этого хотите. Например, есть юридические проблемы с просто обратным проектированием продукта! Но есть необходимые случаи - когда (например) поставщик ушел и больше не существует или не связан с контактами. Хорошим примером может служить редактор WMD, в который вы ввели свой вопрос. Команде SO/сообщество пришлось перепроектировать это из запутанного источника, чтобы применить некоторые исправления ошибок.
Я работал над проектами обратного проектирования, и они, безусловно, не имели никакого отношения к взлому. У нас был исходный код для всех таких проектов (законно), но для одного из проектов никто не знал, что сделал код за кулисами, и как он взаимодействовал с другими системами. Эта информация давно потеряна. В другом проекте у нас был исходный код и документация, но документация не обновлялась, поэтому нам пришлось перепроектировать источник для обновления документации.
Я не против иметь такие проекты на своем резюме. На самом деле, я считаю, что многому научился во время процесса.
Обратная инженерия необходима всякий раз, когда документация теряется или она никогда не существовала. Наличие источника помогает, но вам все равно придется перепроектировать исходную логику, управление потоком и ошибки из него.
Работа со странным оборудованием часто заставляет вас перепроектировать. Например, я когда-то работал со старой карточкой сбора сигналов, которая вела себя странно; вставляя красивую синусоидальную волну, создавали ужасно искаженные данные. Оказалось, что каждый другой байт был двумя дополнениями и каждым другим дополнением - или, по крайней мере, когда это интерпретировалось таким образом, данные стали довольно красивыми. Конечно, это нигде не документировано, и карта отлично работала при использовании ее собственного проприетарного программного обеспечения.
Очень часто (по моему опыту) встречаться с более старым кодом, который имеет дефекты, устарел из-за меняющихся требований или обоих. Часто случается, что неадекватная документация и исходный разработчик (ов) больше не доступны. Обратное проектирование, чтобы код, чтобы понять, как он работает (и иногда принимать решение о ремонте или замене), является важным навыком.
Если у вас есть источник, часто разумно делать небольшую, тщательно спланированную, строго ограниченную сумму очистки. (Я намекаю вслух, что это не может быть разрешено стать воронкой для ценного времени разработчика!)
Также очень полезно использовать код в тестовом стенде либо для проверки того, что он делает то, что ожидалось, либо идентифицирует, документирует, изолирует и устраняет дефекты.
Делать это безопасно требует тщательной работы. Я настоятельно рекомендую книгу Майкла Перса Работа с Legacy Code для практического руководства при тестировании такого кода.
RCE - отличный навык для парней безопасности (исследования, эксплуатация, IDS, IPS, AV и т.д.), но также доказывает, что вы получили глубокое и низкое понимание предмета.
Легко найти свой путь при работе с сторонними библиотеками.
Если вы не работаете в индустрии безопасности, если вы плохо разбираетесь в ASM, не утруждайте себя изучением, как правило, трудно учиться.
Книги
Взлом искусства эксплуатации рассказывает о предмете с точки зрения безопасности.
Также вы можете прочитать книги о Ollydbg и IDA Pro