• XSS.stack #1 – первый литературный журнал от юзеров форума

[Rust] Проблема с обработкой API-forward'ов

reqwest

(L3) cache
Пользователь
Регистрация
05.05.2022
Сообщения
231
Реакции
137
Гарант сделки
2
Депозит
0.00
Всем привет! Реализовал динамический импорт, гоняю юнит-тесты. Ловлю бесконечную рекурсию (ну и STATUS_STACK_OVERFLOW соотв) при попытке резолвинга форварда kernel32.GetThreadDescription -> api-ms-win-core-processthreads-l1-1-3.GetThreadDescription.
Выяснил что при загрузке модуля api-ms-win-core-processthreads-l1-1-3.dll возвращается адрес kernel32.dll.
Минимально воспроизводимый код:
C:
#[test]
fn test() {
    let k32 = LoadLibraryW(w!("kernel32.dll")).unwrap();
    let api_ms = LoadLibraryW(w!("api-ms-win-core-processthreads-l1-1-3.dll")).unwrap();
    // panic if address kernel32.dll == api-ms-win-core-processthreads-l1-1-3.dll
    assert_ne!(k32, api_ms);
}
Как правильно обрабатывать форварды на модули api-ms-*.*.*.dll? Стандарный GetProcAddress обрабатывает их нормально.
 
А что за макрос "w!"?
Функция уходит в бесконечную рекурсию из-за того что вместо api-ms-win-core-processthreads-l1-1-3.dll возвращается адрес kernel32.dll: функция пытается обработать форвард, парсит, загружает либу, парсит таблицу экспорта, видит опять форвард и так по кругу.
 
есть идеи, использовать GetProcAddress, раз не осилил апи форвардинг.
Ну, почему не осилил - kernel32.HeapAlloc -> ntdll.RtlAllocateHeap и прочие нормально резолвятся. Проблема именно с этим форвардом.
 
Проблема именно с этим форвардом.
х#й знает бро, могу тебе на масм пример накидать, твой руст не знаю, или давай семпл без лишнего подебажу.
там же все просто, имя длл для форвардинга и ее грузишь, хз че у тебя там упало
 
Вместо вызова LoadLibraryW для пересылаемых DLL можно вызвать GetModuleHandleW, чтобы получить хэндл DLL
loadlib возвращает хэндл если длл уже загружена, учи матчасть!
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх