Кто сумеет идентифицировать функцию импортируемую из kernel32.dll
она ( Unknown_Kernel32_function ) встречается в таком контексте порядка 20
раз в файле
( листинг получен в IDA, файл PE с поврежденной таблицей импорта, но это с
большой вероятностью ф-я из kernel32,
Unknown_Kernel32_function - имя данное мною )

call CString::~CString()
mov eax,[esi+4]
push ebx
push eax
call dword ptr ds:Unknown_Kernel32_function
push ebx
mov edi,eax
call operator delete(void)

и в таком виде

call CString::~CString()
mov edx,[esi+4]
push esi
push edx
call dword ptr ds:Unknown_Kernel32_function
push esi
call operator delete(void)

Или у кого-то есть какие-то соображения которые сумеют сузить круг
"подозреваемых" функций.

unintruder
А внутри у нее что?

пройдись отладчиком по этому месту, увидишь куда тебя кинет этот call dword ptr ds:Unknown_Kernel32_function

Внимание !!! Файл с поврежденной таблицей импорта. Потому в отладчике я вижу call ds:[Адрес из таблицы импорта] и в результате вызов кода ( случайного ??? ). Но по этому адресу должна быть по всей видимости функция из kernel32.dll. Я так думаю, потому что рядом с этой функцией в таблице импорта функции из kernel32 (т.е. это секция импорта из нее).

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

Мля, ну как дети, поставил бряк на этот неизвестный CALL добился срабатывания, зашёл в CALL и увидел что за функция.

Мля, ну как дети, поставил бряк на этот неизвестный CALL добился срабатывания, зашёл в CALL и увидел что за функция.
а я что сказал?

Посмотреть в отладчике и т.п не выйдет, прога запакована NETHASP-4 и ключа у меня нет. Есть только распакованный дамп. При это на XP стартует, на всем другом нет, нужно править таблицу импорта.

там где должен быть адресс функции из kernel32 стоит снятый с фонаря адрес, именно по нему сейчас и работает call, а мне нужно туда подставить адрес функции. Практически вся таблица импорта уже восстановлена, вопрос только в этой функции. Как еще объяснить я не знаю, всем спасибо.

Уточнение - стартует только на XP без SP и т.п. ( видимо именно на такой конфе распаковывали прогу )

Ты дал мало информации. Хорошо, вижу деструктор. Где замангленое имя деструктора? По нему можно было бы восстановить второй параметр. А так - ну что из этого убогого клочка кода можно сказать? Функция принимает два параметра, один из которых 80% является указателем на какую-то область памяти, которая потом высвобождается, причем не функцией. Сколько, как ты думешь, функций из kernel32 попадают под это определение?

Ну запускай тогда на XP(no SP) и смотри куда ведёт указанный тобой неизвестный CALL.

Копаю в другом направлении. Решил заменить все вызовы этой функции

call dword ptr ds:[00042402B] ;[00042402B] - таблица импорта содержит 0044A789h адрес из секции .protect. Идея заменить все вызовы ф-и прямым переходом на нужный код, а затем в таблицу импорта "вписать" произвольную подходящую ф-ю из kernel32.dll (все равно обращения не будет)

меняю на прямой вызов по адресу 0044A789h ( Image base 400000 )

call 0004A789h.

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

unintruder
Откуда берется значение в esi в обоих фрагментах, а во втором еще и ebx.

Volodya
Кажется, таких функций не очень много :)
all
В первом примере мы сохраняем результат функции, а во втором - нет. Значит ф-ция возвращает что-нибудь вроде BOOL или DWORD.
Потом, второй аргумент - адрес, но по нему расположена не строка (из второго примера).

ИМХО под описание подходит InterlockedExchange :-)
В аттаче список функций экспортируемых из kernel32.dll, которые берут 2 аргумента (надеюсь, полный)

1116778195__fpro_k32.rar

vaskovich
подходит InterlockedExchange
Вторым параметром InterlockedExchange является новое значение. Далее оно используется как параметр operator::delete, значит оно - указатель на некий блок памяти. Объясни, зачем куда-то (первый параметр InterlockedExchange) записывать указатель на тут же освобождаемый блок памяти.

Потом, второй аргумент
Не факт, что аргументов всего два, умные компиляторы могут помещать параметры в стек заранее.

В первом примере мы сохраняем результат функции, а во втором - нет. Значит ф-ция возвращает что-нибудь ... В аттаче список функций экспортируемых из kernel32.dll, которые берут 2 аргумента
Можно исключить из списка функции ничего не возвращающие.