Собственно вот такое было замечено : addr = GetProcAddress(kernel32,"GetProcAddress");
в общем возвращаются адреса не принадлежащие kernel32 фактически, т.е. похереная таблица экспорта в памяти конкретного процесса, ну который отлаживается. в другом процессе, в любом другом, не под отладкой в вижле всё ок и возвращаются адреса больше 0x758F0000. А конкретно в том что-то в районе 0x66000000, та недалеко от BaseAddress. Ну и естественно такой адрес уже в другом процессе недействителен, ибо там кернел под тем же 0x758F0000 загружен, а вот функция ну никак не находиться около 0x66000000. Вот собственно и вопрос : как проще чем просмотр таблицы экспорта самого файла kernel32.dll найти нормальный адрес этой функции вот в таком процессе под отладкой в вижле.

| Сообщение посчитали полезным:

а зачем тебе адрес GetProcAddress, если ты и так ее вызываеш

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

А мне надо её вызывать удалённо, т.е. в другом процессе.

| Сообщение посчитали полезным:

Именно парсить руками. На неё тыкается заглушка из либы ShimEng. А эта либа ввиду ASLR релокабельна, поэтому и адрес в другом процессе другой. Стоит также иметь в виду, что по виртуальному адресу вообще нежелательно с другими процессами играться, на релокабельных либах всё это пахать не будет. Ищи сам базу, парси экспорт, ищи рва и складывай ручками для нужного процесса.

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

kernel32, ntdll и user32 грузятся фиксированному смещению, остальные мелкомягкие либы все релокабельны. Поэтому я и говорю, что лучше сразу делать по уму. По поводу ShimEng (не знаю, она у тебя или нет), она грузится всегда в висте для совместимости, посему руками парсить всё равно не помешает.

| Сообщение посчитали полезным:

multiarc пишет:
Адрес отличается от остальных только под отладкой в вижле. т.е. просто это такая пакостная мелочь, которая просто мешает нормально такое отладить, т.е. не под отладкой всё замечательно... ибо kernel грузиться по одному и тому же адресу на все процессы
С появлением ASLR, не соответствует действительности. Может грузиться на любые адреса.

-----
Реверсивная инженерия - написание кода идентичного натуральному

| Сообщение посчитали полезным:

Ну я говорю про то что вижу, т.е. и под отладкой грузиться она под тем же адресом, только таблицу экспорта чутка переписывает. Т.е. конкретно GetProcAddress(kernel32, "GetProcAddress"); возвращает адрес вне kernel32.

| Сообщение посчитали полезным:

Вопрос уже не совсем актуален, ибо использовал удалённый вызов LdrGetProcedureAddress. Но всё таки остаётся открытым). Т.е. что на самом деле происходит до конца не ясно) Что перекрывает таблицу экспорта kernel32. А точнее сказать кто и зачем. Именно в отладочном билде в Visual Studio 2008, т.е. это делает не сама среда, т.к. запуск просто отладочного билда даёт те же результаты, что и запуск под отладкой среды.

| Сообщение посчитали полезным:

А отладочный билд никаких библиотек студийных (или дополнительных) не вызывает?

multiarc пишет:
Что перекрывает таблицу экспорта kernel32. А точнее сказать кто и зачем.
Наверное перекрывает другая библиотека, наверное для каких-то удобств отладки\тестирования бинарника.

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

Только MSVCR90D.dll но это собственно в опциях компилятора можно поменять. Дело не в ней, адрес куда ведёт переписаный адрес на GetProcAddress находиться в самой сбилженой dll. Зачем и кому это надо буду копать, пока интерес не иссяк) Может чего интересного нарою.

| Сообщение посчитали полезным: