Категория > Новости > Фундаментальные основы хакерства. Продолжаем осваивать отладчик - «Новости»
Фундаментальные основы хакерства. Продолжаем осваивать отладчик - «Новости»9-02-2019, 09:01. Автор: Кирилл |
"); }else{ $('#mpu1-desktop').remove(); console.log('mpu1-desktop removed'); } }); Содержание статьиВ предыдущих статьях мы познакомились с двумя основными типами хакерского инструментария: дизассемблером и отладчиком. Первый служит для статического изучения программного обеспечения, тогда как второй — для динамического. То есть дизассемблер открывает образ файла, хранящегося на носителе, в то время как отладчик раскрывает картину приложения во время выполнения, показывает образ в памяти. В очередной статье цикла мы продолжим изучать глубинное бурение чужого кода.Перемещаемость EXEВ прошлой статье мы остановились на том, что, найдя в памяти с помощью отладчика адреса байтов, которые нужно изменить, мы обнаружили, что в файле на диске таких адресов нет. И какие инструкции в таком случае править? Другими словами, теперь нам надо разобраться, как процесс проецируется в виртуальное адресное пространство, чтобы соотнести адреса байтов, находящихся в памяти, с их реальным расположением в файле на диске. Конечно, у нас есть дизассемблер, с помощью которого мы нашли эти адреса (см. первую статью). Это удалось во многом благодаря тому, что препарируемая нами программа очень маленькая, и нам не составило труда разобраться в ее дизассемблированном листинге. А если бы исследуемая программа весила сотни мегабайт? Также мы выяснили, что PE-файл может быть загружен по адресу, отличному от того, для которого он был создан (это свойство называется перемещаемостью), при этом система автоматически корректирует все ссылки на абсолютные адреса, заменяя их новыми значениями. В результате образ файла в памяти не будет соответствовать тому, что записано на диске. И это происходит после каждой перезагрузки системы, а порой даже перезапуска приложения, всякий раз PE-файл размещается по новому адресу. Вдобавок к этому если раньше (до «Висты») системный загрузчик мог перемещать только DLL (в то же время, если ему не удавалось разместить в памяти по заданным адресам EXE, Windows выдавала ошибку загрузки модуля), то теперь исполняемые файлы тоже подвержены перемещению. Между тем ошибка загрузки модуля происходила довольно редко, потому что, как мы прекрасно знаем, для каждого процесса Windows выделяет независимое виртуальное адресное пространство. Во времена 32-битной Windows это было 2 Гбайт ядерного пространства и 2 Гбайт пользовательского. То есть по факту для процесса выделялось только 2 Гбайт, а 2 Гбайт ядерного пространства были общими для всех процессов, к которым код из пользовательского режима доступа не имел. При включении режима PAE пользовательскому пространству доставалось 3 Гбайт и, соответственно, 1 Гбайт — ядерному. PAE в x86-процессорах стал нужен для работы DEP, препятствующей выполнению кода в секции данных. Он автоматически включен во всех более поздних процессорах. Если пользовательское пространство обособлено для конкретного процесса, то пространство ядра общее для всех привилегированных механизмов, выполняющихся в 0-м кольце. Для x64 картина в целом аналогична. Адресное пространство заметно увеличилось, теоретически до 16 Эбайт. Но, так как современные процессоры фактически используют только 48 бит для адресации пространства, реально используется только малая часть: 8 Тбайт для пользовательского режима и 248 Тбайт для ядерного. Конечно, пока эти размеры кажутся заоблачными — примерно как 4 Гбайт в конце 1980-х. ? Теперь, когда в общих чертах картина обрисована, можно двигаться дальше. Наше приложение passCompare1 откомпилировано 32-битным компилятором. Это позволит нам избавиться от лишних циферок, сохранив при этом смысл происходящего. Итак, чтобы найти адрес нужной инструкции на диске, вкратце повторим последовательность действий из предыдущей статьи, так как за прошедшее время ты наверняка перезагрузил компьютер, поэтому адреса в памяти изменились. Сначала воспользуемся утилитой dumpbin из штатной поставки Visual Studio, на этот раз с ее помощью найдем базовый адрес модуля — тот, с которым работают HIEW (или другой шестнадцатеричный редактор) и дизассемблер: >dumpbin /headers passcompare1.exe Натравим отладчик на подопытную программу. Определим адрес загрузки модуля приложения в памяти (в твоем случае результаты будут другими): 0:004> lmf m passcompare1 Далее нам нужно найти адрес инструкции, которую требуется изменить. Для этого первым делом надо найти расположение эталонного пароля (он находится в секции .rdata), поэтому воспользуемся командой Таким образом, в моем случае секция .rdata начинается с адреса 0xD32000. Немного прокрутив вывод отладчика вниз, я вижу, что пароль располагается по адресу 0xD32108. Теперь нам нужен адрес расположения инструкции в памяти. Не напрягая мозг, легким движением рук поставим бряк на пароль: Если попробовать найти его в файле, то HIEW скажет, что такой адрес отсутствует. Но теперь, когда есть все необходимые значения, нетрудно посчитать, что адрес 0xD310A7 будет соответствовать адресу
Источник новости - google.com
Перейти обратно к новости |