В этой главе мы рассмотрим распакуй-меня, сделанном с помощью упаковщика, который сложно победить в OllyDbg, так как в нём есть одна часть, которая не работает в Олли и выдаёт ошибку. Но мы всё равно будем использовать OllyDbg, несмотря ни на что. Мы могли бы использовать другой отладчик, но ведь это же «Введение в крэкинг с помощью OllyDbg», хе-хе.
Так что даже с распухшими головами мы будем использовать OllyDbg вопреки всему. Распакуй-меня идёт вместе со статьёй, и он кажется реально противоОллиным. Запустим его без отладчика.
Вот в чём дело, когда он запущен, то пожирает 99% ресурсов моей машины. Давайте узнаем, делает ли он это для защиты или ещё почему.
Если хотим приаттачиться к нему, то нужно пойти в FILE-ATTACH и поискать процесс.
И не забудьте приаттачиться.
Если откроем в Ollydbg, пропатченной для поиска OEP, которую использовали в прошлых главах:
Если нажмём кнопку подтверждения:
И если сделаем RUN:
Перезапускаем и снова идём к SYSTEM STARTUP BREAKPOINT, а когда останавливаемся, то идём в окно «M».
Видим, что тут есть одна секция, которая является результатом известной ошибки, когда меняется RVA и размеры в заголовке файла. Пока что установим BPM ON ACCESS на указанной секции. Помним, что эта OllyDbg – особенная, и останавливаемся только на выполнении кода, но не тогда, когда он читается или записывается.
Теперь снимаем BPM и делаем RUN.
Ок, смотрим в заголовке значения RVA и размеров.
Теперь идём вниз, пока не найдём значение.
Вот это значение, которое должно быть равно 10 в шестнадцатеричной системе. Посмотрим, что будет, если мы его изменим.
Пытаемся сохранить изменения.
Грр… Попробуем изменить в шестнадцатеричном редакторе.
Меняем на 10.
Теперь сохраняем изменения.
Сохраняем под другим именем.
Видим, что при открытии в Ollydbg происходит остановка на точке входа (как и должно быть). Починка файла с помощью данного приёма была правильной. Теперь делаем RUN.
ГРРРР… Снова ошибка. Теперь, когда находимся на точке входа, изменим в памяти значения RVA и размеров на те, что были сначала. Это необходимо для правильной распаковки.
Так как мы уже находимся где нужно, установим нужное значение и проверим, сработает ли это.
Значение установили, теперь делаем RUN.
Очевидно, что какая-то часть кода не пролезает через OllyDbg, пробуем оттрассировать, но не встречаем ничего странного, доходим до точки, где совершается переход на несуществующую секцию и до свидания. В OllyDbg не выполняется.
Мы хотим во что бы то ни стало показать методы, которые обычно используются в таких случаях. Здесь нам понадобится что необычное, для этого требуется вдохновение. Отойдём ненадолго, подумаем, что можно придумать такого неожиданного.
ДУМАЕМ
ДУМАЕМ
ДУМАЕМ
хе-хе
ДУМАЕМ ЕЩЁ
Хорошо, я покажу все возможности. Следующий способ мне не помог (но вам нужно быть знакомыми с этими методами, так как часто они работают).
Открываем PARCHEADO 5 и устанавливаем его как JUST IN TIME DEBUGGER, то есть когда программа вызывает ошибку, отладчик автоматом подсоединяется к ней.
Нажимаем эту кнопку, чтобы перевести OllyDbg в режим JIT. Когда закончим работать с OllyDbg, следует восстановить старый JIT-отладчик с помощью кнопки «RESTORE OLD JUST IN TIME DEBUGGER», иначе OllyDbg будет запускаться при каждой программной ошибке, а это весьма утомительно.
Теперь закрываем PARCHEADO 5 и делаем щелчок правой кнопки на исходном файле распакуй-меня. Тот, где мы изменили RVA и другие размеры можно стереть, так как он нам не помог.
У тех из нас, кто иногда использует LORD PE DELUXE в системном меню правой кнопки мыши есть опция «BREAK AND ENTER», которая устанавливает INT3 на точку входа программы, что приводит к ошибке и запуска JIT-отладчика, которая присоединяется к вызвавшему ошибку процессу. Пробуем.
Запускается OllyDbg и присоединяется к процессу. Видим INT3, установленный LordPE. Заменяем INT3 на PUSHAD, который должен быть здесь.
Делаем RUN.
ГРРРРР, так как немного выполняется в OllyDbg, мы должны провести трассировку построчно и выяснить, что происходит, но по-правде, у меня нет никакого желания это делать, поэтому лучше ПОДУМАТЬ, ПОДУМАТЬ, ПОДУМАТЬ, хе-хе.
Всегда будем использовать исходный файл. Откроем его в PeEditor’е.
Теперь смотрим секции.
С помощью PeEditor’а можно прекрасно посмотреть все секции.
Мы ничего не знаем о программе, но очень возможно, что в ней есть функциональность большинства других упаковщиков, которые распаковываются в секцию, начинающуюся с 401000, то есть ту, которая у нас здесь идёт первой, так как здесь не показывается заголовок. Что произойдёт, если изменим параметры доступа к какой-нибудь секции, убрав право на запись, и произойдёт попытка записи сюда? Произойдёт ошибка и откроется PARCHEADO 5, который установлен как JIT-отладчик, хе-хе, так ли это? Можем попробовать это на первой секции, но думаю, что после распаковки программа сохранить API-функции из IAT, и это может быть в следующей секции, поэтому попробуем сначала с ней, а потом, если ничего не выйдет, можем попровать с первой.
Открываем WIZARD, чтобы изменить параметры доступа к секции.
Снимаем галочку с «writeable».
Здесь показаны изменённые параметры секции. Отметим, что автор может оказаться куда умнее меня и несмотря на начальное состояние секции менять права доступа к ней на желамые во время выполнения с помощью API-функции VirtualProtect, но ладно, смотрим.
Запускается этот распакуй-меня, у которого мы изменили права доступа, после чего появляется пропатченный OllyDbg, установленный как JIT-отладчик.
Видим, что программа остановилась, когда попыталась сохранить значение одной из API-функции в вышеуказанной секции (хе-хе, моё предположение было правильным), что привело к ошибке, открывшей OllyDbg, который автоматически подсоединился к программе.
Теперь ,чтобы можно было продолжить выполнение, нужно вручную изменить права доступа к этой секции, чтобы в неё можно было писать. Нажимаем «M».
Неважно, что OllyDbg показывает нам только одну секцию. Делаем следующее: жмём на правую кнопку мыши и устанавливаем полный доступ, то есть «Full access».
Теперь пробуем выполнить инструкцию с помощью F7, посмотрим, нормально ли сохранится или снова выдаст ошибку.
Видим, что сохранилось без каких-либо проблем, теперь запомним как располагаются секции в PeEditor'е, так как OllyDbg нам показывает эту информацию не очень хорошо.
Видим, что первая секция занимает в памяти 1000 байт, так как VIRTUAL SIZE равен 1000, то есть располагается по адресам от 401000 до 402000. Следующая секция, права доступа к которой мы меняли, располагается с 402000 до 403000, хе-хе.
Если посмотрим, что находится в 401000, то увидим, что это распакованная программа.
Так что, хотя не можем установить BPM на всю секцию с помощью карты памяти, так как OllyDbg показывает нам её неправильно, можем отметить в дампе байты с 401000 до 402000, то есть всю секцию, и установить на них BPM ON ACCESS, что по сути будет то же самое.
Затушёвываем всё с 401000 до 402000 и устанавливаем туда BPM ON ACCESS.
Теперь делаем RUN.
Теперь останавливаемся на OEP, который располагается точно в 401000.
Ок, мы сделали самое сложное, теперь нужно сдампить программу.
И сохраняем дам, теперь ищем IAT и данные для IMP REC'а.
Под OEP есть вызов одной API-функции.
И если сделаем FOLLOW, то это приведёт нас к переходам на API-функции.
Так что найти IAT очень просто, посмотрев какой-нибудь из этих переходов, например тот, который ведёт на GetModuleHandleA содержит значение из области 402000, так что оно относится к IAT.
Эта IAT очень маленькая, так что начинается она в 402000, а заканчивается в 40201C, поэтому размер равен 1C. Открываем IMP REC и отнимаем от найденных адресов начала и конца базу образа, то есть 400000.
Заполняем поля для OEP, RVA и SIZE, а затем нажимаем GET IMPORTS. Оно говрит нам, что всё «YES», хе-хе.
Пропускаем дамп через «FIX DUMP», и при запуске нам выдаётся ошибка.
Нам потребуется обработать его в LordPE c помощью «Rebuild PE».
Запускаем, и прощай, упаковщик!
Наши усилия по применению необычных методов дали свои плоды. Некоторые вещи упаковщики делают одинаково, однако они также защищают себя против обычных методов.
Так что даже с распухшими головами мы будем использовать OllyDbg вопреки всему. Распакуй-меня идёт вместе со статьёй, и он кажется реально противоОллиным. Запустим его без отладчика.
Вот в чём дело, когда он запущен, то пожирает 99% ресурсов моей машины. Давайте узнаем, делает ли он это для защиты или ещё почему.
Если хотим приаттачиться к нему, то нужно пойти в FILE-ATTACH и поискать процесс.
И не забудьте приаттачиться.
Если откроем в Ollydbg, пропатченной для поиска OEP, которую использовали в прошлых главах:
Если нажмём кнопку подтверждения:
И если сделаем RUN:
Перезапускаем и снова идём к SYSTEM STARTUP BREAKPOINT, а когда останавливаемся, то идём в окно «M».
Видим, что тут есть одна секция, которая является результатом известной ошибки, когда меняется RVA и размеры в заголовке файла. Пока что установим BPM ON ACCESS на указанной секции. Помним, что эта OllyDbg – особенная, и останавливаемся только на выполнении кода, но не тогда, когда он читается или записывается.
Теперь снимаем BPM и делаем RUN.
Ок, смотрим в заголовке значения RVA и размеров.
Теперь идём вниз, пока не найдём значение.
Вот это значение, которое должно быть равно 10 в шестнадцатеричной системе. Посмотрим, что будет, если мы его изменим.
Пытаемся сохранить изменения.
Грр… Попробуем изменить в шестнадцатеричном редакторе.
Меняем на 10.
Теперь сохраняем изменения.
Сохраняем под другим именем.
Видим, что при открытии в Ollydbg происходит остановка на точке входа (как и должно быть). Починка файла с помощью данного приёма была правильной. Теперь делаем RUN.
ГРРРР… Снова ошибка. Теперь, когда находимся на точке входа, изменим в памяти значения RVA и размеров на те, что были сначала. Это необходимо для правильной распаковки.
Так как мы уже находимся где нужно, установим нужное значение и проверим, сработает ли это.
Значение установили, теперь делаем RUN.
Очевидно, что какая-то часть кода не пролезает через OllyDbg, пробуем оттрассировать, но не встречаем ничего странного, доходим до точки, где совершается переход на несуществующую секцию и до свидания. В OllyDbg не выполняется.
Мы хотим во что бы то ни стало показать методы, которые обычно используются в таких случаях. Здесь нам понадобится что необычное, для этого требуется вдохновение. Отойдём ненадолго, подумаем, что можно придумать такого неожиданного.
ДУМАЕМ
ДУМАЕМ
ДУМАЕМ
хе-хе
ДУМАЕМ ЕЩЁ
Хорошо, я покажу все возможности. Следующий способ мне не помог (но вам нужно быть знакомыми с этими методами, так как часто они работают).
Открываем PARCHEADO 5 и устанавливаем его как JUST IN TIME DEBUGGER, то есть когда программа вызывает ошибку, отладчик автоматом подсоединяется к ней.
Нажимаем эту кнопку, чтобы перевести OllyDbg в режим JIT. Когда закончим работать с OllyDbg, следует восстановить старый JIT-отладчик с помощью кнопки «RESTORE OLD JUST IN TIME DEBUGGER», иначе OllyDbg будет запускаться при каждой программной ошибке, а это весьма утомительно.
Теперь закрываем PARCHEADO 5 и делаем щелчок правой кнопки на исходном файле распакуй-меня. Тот, где мы изменили RVA и другие размеры можно стереть, так как он нам не помог.
У тех из нас, кто иногда использует LORD PE DELUXE в системном меню правой кнопки мыши есть опция «BREAK AND ENTER», которая устанавливает INT3 на точку входа программы, что приводит к ошибке и запуска JIT-отладчика, которая присоединяется к вызвавшему ошибку процессу. Пробуем.
Запускается OllyDbg и присоединяется к процессу. Видим INT3, установленный LordPE. Заменяем INT3 на PUSHAD, который должен быть здесь.
Делаем RUN.
ГРРРРР, так как немного выполняется в OllyDbg, мы должны провести трассировку построчно и выяснить, что происходит, но по-правде, у меня нет никакого желания это делать, поэтому лучше ПОДУМАТЬ, ПОДУМАТЬ, ПОДУМАТЬ, хе-хе.
Всегда будем использовать исходный файл. Откроем его в PeEditor’е.
Теперь смотрим секции.
С помощью PeEditor’а можно прекрасно посмотреть все секции.
Мы ничего не знаем о программе, но очень возможно, что в ней есть функциональность большинства других упаковщиков, которые распаковываются в секцию, начинающуюся с 401000, то есть ту, которая у нас здесь идёт первой, так как здесь не показывается заголовок. Что произойдёт, если изменим параметры доступа к какой-нибудь секции, убрав право на запись, и произойдёт попытка записи сюда? Произойдёт ошибка и откроется PARCHEADO 5, который установлен как JIT-отладчик, хе-хе, так ли это? Можем попробовать это на первой секции, но думаю, что после распаковки программа сохранить API-функции из IAT, и это может быть в следующей секции, поэтому попробуем сначала с ней, а потом, если ничего не выйдет, можем попровать с первой.
Открываем WIZARD, чтобы изменить параметры доступа к секции.
Снимаем галочку с «writeable».
Здесь показаны изменённые параметры секции. Отметим, что автор может оказаться куда умнее меня и несмотря на начальное состояние секции менять права доступа к ней на желамые во время выполнения с помощью API-функции VirtualProtect, но ладно, смотрим.
Запускается этот распакуй-меня, у которого мы изменили права доступа, после чего появляется пропатченный OllyDbg, установленный как JIT-отладчик.
Видим, что программа остановилась, когда попыталась сохранить значение одной из API-функции в вышеуказанной секции (хе-хе, моё предположение было правильным), что привело к ошибке, открывшей OllyDbg, который автоматически подсоединился к программе.
Теперь ,чтобы можно было продолжить выполнение, нужно вручную изменить права доступа к этой секции, чтобы в неё можно было писать. Нажимаем «M».
Неважно, что OllyDbg показывает нам только одну секцию. Делаем следующее: жмём на правую кнопку мыши и устанавливаем полный доступ, то есть «Full access».
Теперь пробуем выполнить инструкцию с помощью F7, посмотрим, нормально ли сохранится или снова выдаст ошибку.
Видим, что сохранилось без каких-либо проблем, теперь запомним как располагаются секции в PeEditor'е, так как OllyDbg нам показывает эту информацию не очень хорошо.
Видим, что первая секция занимает в памяти 1000 байт, так как VIRTUAL SIZE равен 1000, то есть располагается по адресам от 401000 до 402000. Следующая секция, права доступа к которой мы меняли, располагается с 402000 до 403000, хе-хе.
Если посмотрим, что находится в 401000, то увидим, что это распакованная программа.
Так что, хотя не можем установить BPM на всю секцию с помощью карты памяти, так как OllyDbg показывает нам её неправильно, можем отметить в дампе байты с 401000 до 402000, то есть всю секцию, и установить на них BPM ON ACCESS, что по сути будет то же самое.
Затушёвываем всё с 401000 до 402000 и устанавливаем туда BPM ON ACCESS.
Теперь делаем RUN.
Теперь останавливаемся на OEP, который располагается точно в 401000.
Ок, мы сделали самое сложное, теперь нужно сдампить программу.
И сохраняем дам, теперь ищем IAT и данные для IMP REC'а.
Под OEP есть вызов одной API-функции.
И если сделаем FOLLOW, то это приведёт нас к переходам на API-функции.
Так что найти IAT очень просто, посмотрев какой-нибудь из этих переходов, например тот, который ведёт на GetModuleHandleA содержит значение из области 402000, так что оно относится к IAT.
Эта IAT очень маленькая, так что начинается она в 402000, а заканчивается в 40201C, поэтому размер равен 1C. Открываем IMP REC и отнимаем от найденных адресов начала и конца базу образа, то есть 400000.
- RVA или НАЧАЛО: 2000
- SIZE: 1C
- OEP: 1000
Заполняем поля для OEP, RVA и SIZE, а затем нажимаем GET IMPORTS. Оно говрит нам, что всё «YES», хе-хе.
Пропускаем дамп через «FIX DUMP», и при запуске нам выдаётся ошибка.
Нам потребуется обработать его в LordPE c помощью «Rebuild PE».
Запускаем, и прощай, упаковщик!
Наши усилия по применению необычных методов дали свои плоды. Некоторые вещи упаковщики делают одинаково, однако они также защищают себя против обычных методов.
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!