Я не много больше узнал о своей проблеме - она в релоках. Т.е. примерно как описано в статье "последний раз об упаковщиках" ... "БА ! Прямо в центр mov". Единственное там говорилось что это наблюдается когда ImageBase отличен от загружаемого, в моем случае нет. Стандартные утилиты избавления от релоков не помогли, подскажите можно ли продолжать искать функцию kernel ? или это не поможет :).

q_q
Согласен, что подобный пример с InterlockedExchange трудно связать с реальностью, и смысла в подобном действе я, честно говоря, не вижу, но чисто гипотетически так может быть.

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

Можно исключить из списка функции ничего не возвращающие.
Еще можно исключить те, что возвращают хендлы.

Вот, вроде, вообще все возможные функции, которые можно вписать в эти два примера:

BOOL GetComputerName(LPTSTR lpBuffer, LPDWORD nSize);
BOOL GetUserName(LPTSTR lpBuffer, LPDWORD nSize);
BOOL GetProcessShutdownParameters(LPDWORD lpdwLevel, LPDWORD lpdwFlags);
LONG InterlockedExchange(LPLONG Target, LONG Value);
LONG InterlockedExchangeAdd(PLONG Addend, LONG Increment);
DWORD LoadModule(LPCSTR lpModuleName, PVOID lpParameterBlock);

Очень неплохо ложится на эти куски кода LoadModule, но и с ней есть две небольшие неувязки.

Единственное там говорилось что это наблюдается когда ImageBase отличен от загружаемого

Необязательно. Релоки могут создаваться для любого файла. А вот применяются они действительно только в случае загрузки по адресу, отличному от ImageBase.

Мдя, товарищи. Ударились вы в теорию.... Это все хорошо, но весьма малополезно, когда у вас таких функций сотни ;) А надо все-таки опуститься на землю. Дело вот в чем. В новых псаховых конвертиках (апи 9-11) импорты немного "подпорчены". (В более старых они просто не трогались). А именно: вместо адреса функции подставляется адрес "переходника", которых потом вызывает некую универсальную "считалку" адреса. Считалка тупа до безобразия: берет адрес переходника, считает его "номер" в блоке переходников, а потом просто берет адрес функции по этому номеру из некой таблички. Простой плагинчик для ImpRec'а, запущенный на машине ключем, позволяет получить нам полный список... Так что копаем немного глубже, и получаем импорты в чистом виде.... ;)

PS: код плагинчика выглядит примерно так (в значимой части). Смотрим примеры, берем какой-нить tELock.dpr - и усе.

tStart:=dwToTrace and $FFFF0000;
tOffs:=(dwToTrace-tStart) and $FFFFFFF8;
tStart:=tStart - $10000; // адрес таблички относительно блока переходников
tOffs:=tOffs shr 1;
address:=Pointer(tStart+tOffs);
dwPtrOutput^ := address^;

PPS: А релоки псах-конверт не трогает ;)

Успехов. Dixi.

Пока проблему решил. IDA + ImpRec + Hiew рулит, но пришлось много и грязно вычищать код на предмет прямых обращений к kernel32 из секции .protect. В связи с этим возник вопрос, как без использования LoadLibrary можно получить HMODULE например того же kernel32, если он присутствует в таблице импорта ( после восстановления ). Про плагин к ImpRec можно поподробнее ?

Функция GetModuleHandle не поможет?

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

mov eax, 77e567778h
push eax

я делал прямым поиском Kernel IB
и искал ф-ции по таблице импорта.
см. аттач

_300039400__getkib.zip

Про плагин к ImpRec можно поподробнее ?
А куда уж подробнее. Все написано выше. Пишется простой плагин, им обрабатывается Import Table. Существенный код я написал. Берем в комплекте с ИмпРеком какой-нить telock.dpr и вставляем туда этот код. И усе. Импорты у нас в кармане. Если на удаленной машине - скидывается все в файл.... Все достаточно просто... И не надо лишних телодвижений с угадыванием. После восстановления импортов секция .protect откусывается и все. Она вообще-то не нужна нисколько ;)