Проблема в следующем:
В своем отладочном цикле ставлю брекпоинты на WinAPI.
С функциями, вызываемыми из основного процесса, проблем нет.А вот с функциями, которые вызываются до вызова из отлаживаемой проги, вот такая проблема:
При заполнении структуры Context в eip оказывается такая хрень, хотя событие ExceptionBreakpoint и адреса соответствуют ExceptionAddress=APIaddr:

eip: DS:[004B5350]=7C90EB94 (ntdll.KiFastSystemCallRet)

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

BoOMBoX/TSRh пишет:
А вот с функциями, которые вызываются до вызова из отлаживаемой проги
Нихрена не понял, кто от куда вызывается?

-----
Yann Tiersen best and do not fuck

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

PE_Kill пишет:
Нихрена не понял, кто от куда вызывается?


Уточним:
Когда вызывается функция, допустим MessageBox из отлаживаемой проги, то все ок.
А вот, когда прога при загрузке подгружает допустим Advapi.dll, а она уже, в свою очередь вызывает MessageBox, то теоретически мы должны остановиться в теле Advapi.dll, но этого не происходит, хотя exception происходит именно на нужном адресе, только вот в context лезет какая-то пурга.

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

BoOMBoX/TSRh пишет:
А вот, когда прога при загрузке подгружает допустим Advapi.dll, а она уже, в свою очередь вызывает MessageBox
Разве в адвапи длл есть форварды на юзер длл ? Если и есть, то явно не мессаджбоксовские

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

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

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

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

Smon
Это было сказано для примера.

BoOMBoX/TSRh
Не очень понял, при чем тут SetThreadContext? мб GetThreadContext?

В ольке, например, если самому приостановить поток, то его EIP = ntdll.KiFastSystemCallRet.
Может быть ты читаешь контекст другого потока?..

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

Скорее всего дело действительно в кривой реализации, т.к. у мну в отладчике всё нормально

-----
Yann Tiersen best and do not fuck

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

HoBleen пишет:
Может быть ты читаешь контекст другого потока?..

Это очень похоже на правду, только как корректно реализовать пока не нашел.
Изначально работал в Get/SetThreadContext с параметром pi.hThread, когда все вызовы идут только из самой проги, то все нормально.
Потом пробовал создать список всех потоков с их хэндлами (при событиях CreateProcess и CreateThread events) и написал функцию, возвращающую хэндл по ID потока, т.е. при возникновении события ExceptionBreakpoint на нужной API получаю хэндл так:
GetCurrentHandle(DebugEvent.dwProcessId) но толку не дало. Все тоже самое.
Как же получить хэндл текущего потока (в котором произошло исключение?).

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

BoOMBoX/TSRh
удивительно сумбурное у тебя изложение сути вопроса, я так и не понял =)

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

BoOMBoX/TSRh
Привел бы кусочки кода, чтобы не объяснять на пальцах.

-----
Сколько ни наталкивали на мысль – все равно сумел увернуться

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

я вроде понял в чём проблема))) но не понял почему
попробуй чтото типа этого:

CurThread:=OpenThread(THREAD_ALL_ACCESS,false,de.dwThreadId)

з.ы. http://vsokovikov.narod.ru/Msdn_api/Global_SDK/Reference_API/Functions /Fn_O/fn_openthread.htm http://vsokovikov.narod.ru/Msdn_api/Global_SDK/Reference_API/Functions/Fn_O/fn_openthread.htm

-----
[nice coder and reverser]

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

ValdiS пишет:
Привел бы кусочки кода, чтобы не объяснять на пальцах.

Да привел бы, только что конкретно.
Вопрос то локализовался, как получить "правильный" хэндл потока, в котором произошло брекпоинтовое исключение?

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

__ пишет:
удивительно сумбурное у тебя изложение сути вопроса, я так и не понял =)

Кто в теме я думаю поймет, а как еще проще объяснить проблему, не знаю.

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

Hellspawn пишет:
CurThread:=OpenThread(THREAD_ALL_ACCESS,false,de.dwThreadId)

В MS API не нашел такую функцию

уже нашел в новом MSDN. Как вариант на NT системах пройдет похоже, а как же все-таки этот приславутый хэндл получить под 9x?

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

__ пишет:
удивительно сумбурное у тебя изложение сути вопроса, я так и не понял =)
Прерываясь на брекпоинте, BoOMBoX/TSRh читал контекст главного потока, а не того, который вызвал исключение.

BoOMBoX/TSRh пишет:
В MS API не нашел такую функцию
OpenThread существует!! Правда, например, в хелпе дельфика её нету
Её описание - в ссылке Hellspawn'а.

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

Kernel 4.90.3000 из под Win ME - ф-я OpenThread. Видимо, она была просто неполностью документрирована

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

поиск надо юзать и под 9х мона, один из способов:

function OpenThread9x2(
dwAccess: DWord;
bInheritHandle: Boolean;
dwThreadID: DWord
): DWord; stdcall;
var
pTDB : Pointer;
pOpenProcess: Pointer;
OpenThread : Pointer;
begin
Result := 0;
pTDB := Pointer(dwThreadID xor GetObsfucator);
if IsBadReadPtr(pTDB, 4) then
Exit;
pOpenProcess := GetProcAddress(GetModuleHandle('kernel32.dll'),'OpenProcess');
if (pOpenProcess = nil) then
Exit;
if (PByte(pOpenProcess)^ = $68) then
pOpenProcess := PPointer(Pointer(DWord(pOpenProcess)+1))^;

OpenThread := Pointer(DWord(pOpenProcess)+$24);
asm
PUSH DWORD PTR [dwAccess]
PUSH DWORD PTR [bInheritHandle]
PUSH DWORD PTR [dwThreadID]
MOV EAX, DWORD PTR [pTDB]
CALL OpenThread
MOV Result, EAX
end;
end;

-----
[nice coder and reverser]

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

PE_Kill пишет:
Скорее всего дело действительно в кривой реализации, т.к. у мну в отладчике всё нормально

Ну, если бы реализация была прямая, то вопрос бы и не возник

А ты OpenThread юзаешь?

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

BoOMBoX/TSRh
посмотри исходники плагина Red Plait'а(встроенный перл для IDA), там есть необходимый код,
правда немного замусорен перловыми API, но суть понятна

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

__ пишет:
посмотри исходники плагина Red Plait'а(встроенный перл для IDA), там есть необходимый код,
правда немного замусорен перловыми API, но суть понятна

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

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

у RedPlait'а используется OpenThread (смотри mydbgxs.cpp), возможно это единственный верный подход

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

__ пишет:
RedPlait'а используется OpenThread (смотри mydbgxs.cpp), возможно это единственный верный подход

Посмотрю обязательно, но в nwDebugger и без использования OpenThread, все работает как положено.
Хочу разобраться сначала с этим.

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

BoOMBoX/TSRh я использую OpenThread, хотя первая версия была без него. При создании потока тебе дается его хэндл, так вот ловишь все создания потоков и сохраняешь в массив структур
TID: DWORD;
TH : DWORD;
При убивании потока удаляешь оттуда. При возникновении отладочного события по TID ищеш хэндл в массиве и юзаешь. Но мне такой геморой не нужен, мне и NT хватает вот я и юзаю OpenThread.

-----
Yann Tiersen best and do not fuck

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

> eip: DS:[004B5350]=7C90EB94 (ntdll.KiFastSystemCallRet)

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

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