сбрасывали от визуальной студии:Почему сборка не соответствует мне?
CheckPointer(pReceivePin,E_POINTER);
017D616D cmp dword ptr [ebp+0Ch],0
017D6171 jne CBasePin::Connect+4Dh (17D617Dh)
017D6173 mov eax,80004003h
017D6178 jmp CBasePin::Connect+1A7h (17D62D7h)
Но фактическое определение:
#define CheckPointer(p,ret) {if((p)==NULL) return (ret);}
Хотя моя сборка не так хорошо, я не вижу никакого отношения между источником и ассемблером.
Вы упустили достаточно, чтобы было трудно быть уверенным, но часть, которая может быть разобрана, выглядит разумной. NULL == 0, так:
017D616D cmp dword ptr [ebp+0Ch],0 ; if [ebp+0ch] == 0
017D6171 jne CBasePin::Connect+4Dh (17D617Dh) ; goto 172617dh
017D6173 mov eax,80004003h ; else load 'ret'
017D6178 jmp CBasePin::Connect+1A7h (17D62D7h) ; and return it.
Очевидная проблема в том, что вы не показали нам, что в 17D617Dh или 17D62D7h, поэтому мы не можем угадать, что на самом деле делается со значениями.
Вероятно
CheckPointer(pReceivePin,E_POINTER);
017D616D cmp dword ptr [ebp+0Ch],0
017D6171 jne CBasePin::Connect+4Dh (17D617Dh)
017D6173 mov eax,80004003h
017D6178 jmp CBasePin::Connect+1A7h (17D62D7h)
pReceivePin случается быть расположен по адресу, хранящейся на стеке - это, как правило, получает доступ с помощью косвенности, используя значение в магазин ebp.
Это значение сравнивается с нулевым, и если оно равно нулю (jne не пнуть в) фактическое значение E_POINTER перемещается в eax (eax используется для хранения возвращаемого значения функции) и управление передается эпилог функции, в котором выполняется очистка, а затем управление возвращается вызывающему абоненту (инструкция ret). Если значение pReceivePin не является нулевым (jne делает удар), управление передается в другое место, где сохраняется код, который был после CheckPointer, и этот код затем выполняется.
Почему вы упоминаете 'ret', нет такой инструкции в моей свалке, так? – ollydbg
@ollydbg: Это где-то еще. Попробуйте вызвать этот код с 'pReceivePin', который будет иметь нулевой код, выполнит' jne' и прибудет на epligue, где 'ret'. – sharptooth
Вам нужно предоставить больше контекста, но, вполне возможно, последняя строка переходит к завершающим частям функции CBasePin :: Connect, которая вскоре следует с RET. Это вполне соответствует логике вашего макроса. Вторая строка скачет сразу после последней строки, если указатель не равен нулю (т. Е. Null).
Сборка выглядит отлично.
cmp dword ptr [ebp+0Ch],0 сравнение на pReceivePin с NULL. pReceivePin - локальная переменная внутри вашей функции, поэтому ее адрес является смещением от начала фрейма стека функции. ebp содержит адрес начала кадра стека. 0Ch - это смещение pReceivePin внутри рамки стека. Все локальные переменные в вашей функции будут рассмотрены как [ebp + something], за исключением параметров. Параметры обычно адресуются как [ebp - something].
mov eax,80004003h - это не что иное, как E_POINTER значение, размещенное в области «возвращаемого значения» функции (для этой цели используется регистр eax).
Конечный jmp посылает контроль на эпилог код текущей функции (CBasePin::Connect), который заканчивается в ret команды (и «возвращает» текущей eax значения, т.е. E_POINTER)
Середины управление jne Sens к код сразу после вашего макроса, если pReceivePin не равно E_POINTER.
Почему 'pReceivePin' расширена до' [ebp + 0Ch] '? – ollydbg
@ollydbg: он хранится в стеке и доступен через косвенный режим. – sharptooth
@ollydbg: См. Редактирование. – AnT
Настоящий Олидбг, конечно, знает! «Jmp' начинает выполнять код по указанному адресу. «Вызов» делает то же самое, но сначала он подталкивает текущий адрес в стеке, поэтому «ret» может продолжить возврат туда. –
Не текущий адрес, но адрес следующей инструкции, если быть точным. – ollydbg
@ollydbg: Я действительно намеревался что-то более похожее на «адрес в настоящее время в EIP», но да, это будет адрес, следующий за текущей инструкцией (хотя в действительно * ранних * x86-процессорах это не так), что вызвало проблему с обработка исключений в нескольких странных случаях). –