Для самое сложно в реверсинге, как для новичка, это поиск OEP и распаковка программ. Как с этим разобраться, как вы с этим разбирались? Как находить OEP, как понять саму логику поиска OEP? Аналогично, как понять где код пакера, а где начинается программа. В туториалах эти две узкие темы разбираются очень плохо. Кто может, объясните на пальцах.
черти подписку проталкивают хотя в общем и целом в начале статьи дан необходимый перечень инструментов == дальше можно не читать
Tritex, качаешь архив crackmes.de и ломаешь от простого к сложному. все вопросы отпадут во время работы - ты сам их сформулируешь и найдешь ответы в гугле. по пакерам начни с upx, а не с вмп (этот лол конечно) и после крякмиксов.
Ну торренты никто не отменял вообще то Эт пример оч простой упаковки. Как раз для новичков, что бы понять, как все устроено, как и где код распаковывается, как выглядят переходы на распакованный код и так далее...
Tritex, вообще, хорошие и правильные вопросы задаете, видно, что пытались разобраться. Нужно понимать, как работает распаковщик(сферический). Ну тоесть вы загрузили файл в отладчик, понимаете, что он упакован(код не проанализировался). Как работает распаковщик? Начинаем искать winapi, которые выделяют память, меняют атрибуты достпа к ней(ведь код распаковывается в память, верно? Дампим мы ведь ее). Да, надо уметь "читать" код - но это дело наживное, со временем глаз сам начинает цепляться за имена апишек, а мозг начинаеть видеть логику распаковки. Вы понимаете изначально, чего нужно ждать от кода. В итоге в отладчике вы оказываетесь где то в регионе памяти, а перед вами стандартный пролог... Это все утрированно, но это вектор. Инфа есть, на самом деле. Инструменты годные тоже. Многие советуют начитать с upx и aspack - не знаю, эта гадость слишком проста даже для чайников
главным индикатором успешной распаковки являются таблицы импорта: их можно сверять чрез отладчик и, более того, сий процесс можно ставить на автомат. все юм упаковщики по определению слабоваты == они не могут эффективно ронять отладчик.
почему? акий толк от упаковщика, если отладка "гладкая"? конечно, полный автомат мб и не очень эффективным, однако режим полуавтомата весьма хорош.
Использование гуя это событие запуска апп после анпака, обычно всегда так. Прежде может быть стандартная инициализация. Нужно каким то образом отслеживать это событие и вернуться немного назад, что бы найти EP.
Не так и уж плохо... Мне лично из обсуждения IDA суть упаковщиков была понятна, хот и были затруднения.
Tritex, Снимать" значит восстановить распакованный модуль. Обычно пакеры так устроены, что настраивают образ в памяти. Иначе в динамике это было бы сложно, не тот уровень у авторов этих поделок, что бы собирать трассу в динамике. Поэтому метод штатный - дождаться настройки образа, дампить и фиксить IAT etc согласно формату. В таком случае поиск события окончания депака важен - переменные должны быть не инициализированы. Если это событие пропустить, то дамп окажется не рабочим.
Tritex, Суть упаковщиков. Процитирую Нарвахо в руссом переводе: "Когда приложение упаковывается выбранным упаковщиком, тот шифрует и хорошо прячет изначальный (исполняемый, а не исходный) код программы, затем, обычно, добавляет одну (или больше) секцию, в которую помещает загрузчик, и перенаправляет точку входа на этот загрузчик-распаковщик. В результате всего этого изначальный код программы становится не виден, если откроем программу в OllyDbg и остановим её, то окажемся в точке входа распаковщика, откуда и будет начинаться выполнение. Этот распаковщик ищет сохранённую информацию о зашифрованном изначальном коде, расшифровывает её и сохраняет в изначальное места. Как только раскриптовка завершена, он переходит на OEP или изначальную точку входа (Original Entry Point), т.е. та, которая была до упаковки программы" . Упакованный файл - это программа, содержащая несколько секций и код распаковщика в специально созданной секции, где расположена ее точка входа (EP). Как правило, контейнер с зашифрованным файлом (это длинный блок данных, зашифрованная строка, если хотите) расположен в другой секции. Большая часть программ имеют базу 400000 и смещение первой секции в памяти = 1000, поэтому простые упаковщики, такие как upx, создают в упакованном файле первую пустую секцию c нулевым размером и виртуальным размером, равным размеру образа исходного файла после настройки его в памити загрузчиком Windows. Это значит, что в памяти код загрузчика, его ресурсы расположены ниже кода исходного файла, ниже его секций кода, данных и ресурсов после настройки образа исходного файла. Когда упаковщик расшифрует и настроит весь образ исходного файла, разрешение его секций, он передает управление на OEP - точку входа исходного файла. После этого код упаковщика уже не нужен, обычно он висит мусором в памяти до закрытия программы. Вся методика поиска OEP заключается в определении момента передачи управления от кода упаковщика коду распакованной программы.См. "Глава 32 - Методы нахождения OEP" туториала Рикардо Нарвахо. В комерческих программах этот процесс осложняется методами противодействия отладке, эттачу и снятию дампа (прога либо работает неправильно, либо закрывается вместе с отладчиком). Я проверял работу блокнота, упакованого up. Cнимал дамп на OEP и после запуска и эттача к процессу в петулс, чинил IAT и проверял работу. Работает. Во втором случае образ содержит инициализированные данные и скорее всего уже измененный код программы. Практически невозможно найти OEP.
