Я программист, а то что я еще и реверсер - ну... так совпало. И как любому из людей занимающимся реверсом мне всегда не хватает функционала отладчика. Постоянно приходится допиливать под конкретную задачу какие-то утилитарные вещи и однажды...
Однажды я решил - хватит, каждый раз пилить новое достаточно утомительно, а что если взять и объединить все наработки в один инструмент и пользоваться именно им!
Это будет скорее рекламный пост - но не спешите минусовать, возможности утилиты, о которой пойдет речь, а называется она Process Memory Map, весьма обширны, и возможно вам понравится :)
Итак - что это такое? Она похожа на всем известный инструмент от Марка Руссиновича VMMap (которая кстати частично основана на коде Джефри Рихтера), её задача проанализировать сторонний процесс и вытащить из него максимум данных, о которых она знает.
А знает она весьма много, для начала она умеет работать с кучей системных структур и размапливать их. Давайте просто перечислю по порядку.
-
KUSER_SHARED_DATA - здесь сидит куча системной информации, опорные данные для GetTickCount, флаги процессора, флаги отладочной типа KdDebuggerEnabled и много всего интересного.
-
Списки загрузчика - если вам встречалась антиотладка, мешающая аттачу отладчика к процессу посредством манипуляции списками (через сброс линков), PMM их покажет
-
Естественно она знает о PEB, причем отобразит как 32 битный PEB так и 64 битный
-
Она знает о структуре ApiSet таблиц используемых для редиректа библиотек из таблиц импорта исполняемых фалов
-
PROCESS ACTIVATION CONTEXT - тоже умеет
-
Параметры процесса - легко
-
Конечно же TEB
Впрочем если перечислять все типы структур - это будет слишком объемная статья. По хоткею F2 PMM предоставит быстрый доступ ко всей требуемой информации о которой она знает на текущий момент.
Конечно же основным режимом работы является работа с образами исполняемых файлов, они целиком размаплены и можно увидеть всю их структуру с секциями директориями, заголовками и прочим - причем с учетом актуального состояния в памяти.
Знает о структуре таблиц импорта экспорта, TLS и всем что может потребоваться реверсеру.
Безусловно - дизассемблер в наличии, причем есть два движка работы с отладочной информацией (один под MAP и второй под работу с COFF/DWARF2-3). Вот так выглядит точка входа при подключенной отладочной.
Конечно есть актуальный список экспорта всех загруженных в процесс библиотек, куда сразу подтягиваются данные из отладочной. К диалогу подключен быстрый поиск.
Как и у любого уважающего себя инструмента анализа - присутствует список строк, найденных в удаленном процессе.
Отдельно хочется упомянуть что присутствует модуль сканера перехваченных вызовов (F8). Очень удобный инструмент для детектирования работы песочниц.
Ну и конечно присутствует вывод детального CallStack всех потоков приложения (F4), включая 64 битный стек Wow64 подсистемы для 32 битных приложений и их список SEH фреймов. Стеки развернуты с учетом отладочной информации (если она присутствует).
Утилита постоянно дорабатывается, люди, которые ей пользуются постоянно присылают новые идею по внедрению нового функционала. Собственно и этот рекламный пост был сделан именно с этой целью - найти новых пользователей которые помогут развитию функционала новыми идеями.
Конечно же это полный опенсорс, т.е. - даром :)
https://github.com/AlexanderBagel/ProcessMemoryMap
Планов по развитию еще очень много (тот же PDB еще не подключен, планируется реализовать чтение сразу в RAW формате).
Есть конечно в ней и недочеты - например прямо сейчас снимая скриншоты к статье обнаружил что отвалилось обработка Forward функций в сканере хуков, но это все чинится (но после НГ).
Кстати всех с наступающим!
Комментарии (15)
rsashka
30.12.2023 11:14+2Конечно же это полный опенсорс, т.е. - даром :)
Не вводите людей в заблуждение и сами от них избавляйтесь. Просто модели коммерциализации СПО сложнее, чем у проприетарного кода. Более того, вопрос "заработать денег на ПО", это вопрос вообще не технический.
Может случиться так, что один и тот же функционал, но под другой операционкой не будет пользоваться спросом в силу некоторых обстоятельств (например, имеются бесплатные аналоги). В этом случае с коммерциализацией ПО может вообще ничего не получится не зависимо от лицензии и доступности кода.
Ведь пользователь платит либо за понты, либо за решение своих проблем. Но это вовсе не означает, что ваша проблема присутствует у кого-то еще и этот кто-то готов за решение такой же проблемы вам заплатить.
Сразу прошу прощение за немного демотивирующий комментарий, но считаю, что лучше сразу показать правильное направление, ведь это может сэкономит месяцы и годы жизни.
Rouse Автор
30.12.2023 11:14+5Этот проект действительно полный опенсорс, я его развиваю уже лет 12 и буду продолжать развивать, монетизировать его как-то у меня даже не было в планах (хоть и хотелось бы). Может быть (конечно с большой оговоркой) когда-то от него будет сделан коммерческий форк с новыми фишками, но это только в том случае если мой работодатель будет заинтересован в их продаже. И даже в этом случае в текущий вариант просто не будут включены эти новые фишки и он останется открытым. А сейчас я его пилю прежде всего для себя ( у меня это один из основных инструментов для отладки) ну и с целью показать народу некоторые вещи как нужно делать.
А линуксовая разработка - мне её сразу запретили выкладывать в опенсорс ибо работодатель имеет на неё виды в плане коммерции.rsashka
30.12.2023 11:14+2А линуксовая разработка - мне её сразу запретили выкладывать в опенсорс ибо работодатель имеет на неё виды в плане коммерции.
Ну тогда все гораздо проще. Если работодатель оплачивает разработку, то вас вообще не должна волновать лицензия на ПО, т.к. результаты вашей работы принадлежат не вам, но и коммерческий риск вы на себя не принимаете.
Когда то давно у меня не получилось, подобно вам, договориться с работодателем о публикации исходного кода приложения. Но потом я стал делать немного по другому, если возникает необходимость в разработке какого либо сугубо технического функционала (не большая библиотека, которая не несет самостоятельной коммерческой ценности), я сперва завожу публичный репозиторий для разработки этой библиотеки под копилефтной лицензией, и только потом её цепляю к основному проекту. И только после этого с чистой совестью начинаю её разработку (публиковать в дальнейшем изменения или нет, это уже отдельный вопрос).
otchgol
30.12.2023 11:14Так удивительно в 23 году видеть слово Delphi. Наверное здорово, что остались люди, продолжающие работать с ним. Дельфовый разбор очень геморный. Если в VCL еще можно что-то копать, то дальше от окон уходят и точки входа искать все сложнее. Но я видел много проектов, где частичные возможности устраивали пользователей. В любом случае желаю успехов!
Rouse Автор
30.12.2023 11:14Именно разбор дельфи исходников достаточно геморный, но помимо этого есть еще и Lazarus. С ним сейчас куча проблем и после того как я подключил отладочный COFF/DWARF стало уже сильно полегче. Ибо сейчас как раз занимаюсь портированием кода под линукс, и когда что-то не работает приходится уходить в отладку, причем я еще не сильно освоил линевые отладчики, поэтому приходится компилить под винду (благо Gtk рантайм и там есть) и отладивать бинарь прямо на месте.
Pavia00
А планируется версия под Линукс?
Rouse Автор
Да - но уже не опенсорс
Rouse Автор
Поправлюсь - в рамках расширенного коммерческого пакета, там помимо этого будет еще мнго вкусностей.