смотрим какие dll'и загрузил процесс, определяем адреса экспорируемых ими функций, затем пытаемся найти их в файле. если много-много адресов будут сосредоточены в одном месте - то это 100% IAT.

Кхе-кхе.
Пара возражений.
1) Мне известны пакеры, специально подгружающие ненужные длл в свое адресное пространство. Кому нужен поиск левых апи?
2) Как правило, сейчас адреса апи в IAT подменяются на адреса переходников, так что "100% IAT" - это, конечно, на 100% сказано верно, но на 101% вернее, что так ее не найти.

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

> бо надурить могут

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

это только примитивные пакеры/протекторы оставляют структуру секций более или менее неизменной. нормальный же пакер/протектор оставляет только одну секцию и кидает в нее все,а уже потом разворачивает файл в памяти. так что анализировать дисковый образ я бы не стал - пустая трата времени...