Захват всех распределений кучи - PullRequest
2 голосов
/ 03 мая 2020

Я хочу найти все обращения к куче памяти в приложении. Мне нужно хранить каждое выделение и, следовательно, можно не только проверять адреса в диапазоне [heap] (который также не включает области памяти кучи, выделенные mmap()). Поэтому я написал pintool и перехватил все звонки на malloc(), calloc(), realloc() и free(). Из-за таких оптимизаций, как устранение хвостовых вызовов, Pin не может обнаружить последнюю инструкцию этих вызовов. Поэтому я вручную добавил обратные вызовы после (точнее, я использовал IPOINT_TAKEN_BRANCH) инструкций ret... в каждой из вероятных целей прямого / косвенного перехода из этих функций (например, malloc(), косвенно, переходит на malloc_hook_ini(). Поэтому я добавил код инструментария после всех ret... инструкций в malloc_hook_ini()). Сами эти цели могут иметь исходящих прямых / косвенных прыжков и, опять же, я пытался их поймать.

Но в * все еще есть некоторые доступы Диапазон 1025 * (а также в диапазонах mmap()), которые не относятся ни к одному из ранее захваченных распределений. Чтобы устранить любые сомнения, я использовал Pwngdb , чтобы отобразить все выделенные в настоящий момент куски кучи, прямо перед точкой доступа. Адрес доступа был четко выделен в куче кучи. Конечно, знание IP распределения для этих кусков кучи будет большой помощью. Но это не поддерживается в Pwngdb или любых других подобных инструментах.

Во многих случаях, анализируемых с помощью Pin, адрес доступа не принадлежит ни одному выделенному диапазону адресов (даже тем, которые были удалены за это время) выполнение всей программы. Как определить, какая функция распределения была пропущена во время анализа Pin?

Кажется, что возможны две ситуации:

1) Существует некоторая пропущенная функция, другая чем malloc(), calloc(), realloc() и free().

2) Есть несколько пропущенных точек возврата для malloc(), calloc(), realloc() и free().

Второй кандидат невозможен. Поскольку я поставил счетчик до и после каждой из этих функций распределения и в конце, они имели равных значений.


ОБНОВЛЕНИЕ:

Вот обратная трассировка для одной такой точки доступа, а также значение для регистра RSI: enter image description here

...