В стек main thread'а динамически заливаются значения, источник которых надо узнать. Пошаговое исполнение вывело на следующий код: Код (Text): 01194BEA . 8D35 509F2001 LEA ESI,DWORD PTR DS:[1209F50] 01194BF0 . EB 05 JMP SHORT GWSrv32.01194BF7 01194BF2 $ E8 0D000000 CALL GWSrv32.01194C04 01194BF7 > B9 30000000 MOV ECX,30 01194BFC . 57 PUSH EDI 01194BFD . FC CLD 01194BFE > AD LODS DWORD PTR DS:[ESI] 01194BFF . E8 2C000000 CALL GWSrv32.01194C30 01194C04 $ 5B POP EBX 01194C05 . 5A POP EDX 01194C06 . 83C4 04 ADD ESP,4 01194C09 . 51 PUSH ECX 01194C0A . 50 PUSH EAX 01194C0B > 8A03 MOV AL,BYTE PTR DS:[EBX] 01194C0D . 32C8 XOR CL,AL 01194C0F . C1C1 04 ROL ECX,4 01194C12 . 02C8 ADD CL,AL 01194C14 . C1C1 04 ROL ECX,4 01194C17 . 2AC8 SUB CL,AL 01194C19 . C1C1 04 ROL ECX,4 01194C1C . 43 INC EBX 01194C1D . 3BDA CMP EBX,EDX 01194C1F . 72 EA JB SHORT GWSrv32.01194C0B 01194C21 . 58 POP EAX 01194C22 . 33C1 XOR EAX,ECX 01194C24 . 59 POP ECX 01194C25 . AB STOS DWORD PTR ES:[EDI] 01194C26 . E2 D6 LOOPD SHORT GWSrv32.01194BFE 01194C28 . 5F POP EDI 01194C29 . FFD7 CALL EDI К этому моменту область стека заполнена нулями. Регистры выглядят так: После CALL EDI по адресу 001296В0 находится значение 00000FAB, соседние ячейки также заполнены константами. Функция по адресу 00129258 выглядит довольно странно... и странно выполняется: Код (Text): 00129258 55 PUSH EBP 00129259 88FC MOV AH,BH 0012925B 81EC 79980300 SUB ESP,39879 00129261 4C DEC ESP 00129262 CC INT3 00129263 54 PUSH ESP 00129264 EB 14 JMP SHORT 0012927A 00129266 ^ 73 91 JNB SHORT 001291F9 00129268 0003 ADD BYTE PTR DS:[EBX],AL 0012926A 9A 5456C813 760>CALL FAR 0C76:13C85654 ; Far call 00129271 BA 3B03FD1E MOV EDX,1EFD033B 00129276 ED IN EAX,DX ; I/O command 00129277 AC LODS BYTE PTR DS:[ESI] 00129278 0FB552 C2 LGS EDX,FWORD PTR DS:[EDX-3E] ; Modification of segment register 0012927C E1 0D LOOPDE SHORT 0012928B 0012927E 2103 AND DWORD PTR DS:[EBX],EAX 00129280 00AF 98FF57AD ADD BYTE PTR DS:[EDI+AD57FF98],CH 00129286 CC INT3 00129287 53 PUSH EBX 00129288 53 PUSH EBX 00129289 52 PUSH EDX 0012928A 11C0 ADC EAX,EAX 0012928C E8 CC65FCFF CALL 000EF85D 00129291 2D 11F08BCB SUB EAX,CB8BF011 00129296 B1 C8 MOV CL,0C8 00129298 E8 1E9A0300 CALL 00162CBB 0012929D F1 INT1 0012929E /7D 00 JGE SHORT 001292A0 001292A0 \00FF ADD BH,BH 001292A2 025B 58 ADD BL,BYTE PTR DS:[EBX+58] 001292A5 2F DAS 001292A6 12C2 ADC AL,DL 001292A8 AA STOS BYTE PTR ES:[EDI] 001292A9 40 INC EAX 001292AA BC D958A0C5 MOV ESP,C5A058D9 001292AF 5C POP ESP 001292B0 FF62 93 JMP DWORD PTR DS:[EDX-6D] 001292B3 FC CLD 001292B4 D0A2 4107EB44 SHL BYTE PTR DS:[EDX+44EB0741],1 001292BA 2120 AND DWORD PTR DS:[EAX],ESP 001292BC 90 NOP 001292BD A2 F386C09B MOV BYTE PTR DS:[9BC086F3],AL 001292C2 94 XCHG EAX,ESP 001292C3 55 PUSH EBP 001292C4 51 PUSH ECX 001292C5 8AD4 MOV DL,AH 001292C7 2BF0 SUB ESI,EAX 001292C9 88C2 MOV DL,AL 001292CB E8 03395E00 CALL 0070CBD3 001292D0 59 POP ECX 001292D1 49 DEC ECX 001292D2 98 CWDE 001292D3 AC LODS BYTE PTR DS:[ESI] 001292D4 32C3 XOR AL,BL 001292D6 09E8 OR EAX,EBP 001292D8 0903 OR DWORD PTR DS:[EBX],EAX 001292DA 5E POP ESI 001292DB 005A F8 ADD BYTE PTR DS:[EDX-8],BL 001292DE 6C INS BYTE PTR ES:[EDI],DX ; I/O command 001292DF 0B33 OR ESI,DWORD PTR DS:[EBX] 001292E1 CF IRETD 001292E2 61 POPAD 001292E3 EC IN AL,DX ; I/O command 001292E4 C3 RETN После третьего шага - SUB ESP,39879 - окно стека Ollydbg просто очищается и попытка затолкать в стек ESP на пятом шаге - приводит к завершению приложения. Я не понимаю, как с этим бороться... Помогите, пожалуйста.
Извини, я не так опытен, как ты... Пожалуйста, объясни подробней! xlatb я нашел в инете, почитал про команду. Как это связано с моей проблемой?! Не вижу в своем тексте 0D7h *********** Если снять останов с CALL EDI - с предущего останова исполнение пролетает этот main thread до следущего в GWSrv32. А при пошаговом рубится. Подозреваю, что это что-то типа антиоладки...
Tihon Инвалидация стека происходит. Всякое исключение при не валидном стеке приводит к завершению ядром процесса.
Вопрос все еще актуален. Причем обнаружились пикантные поробности... 1. Бряков нет... Исполняется без проблем. 2. Бряк на 01194C29 CALL EDI (см. 1-й пост!) Майн тред дизассемблируется так, как приведено в первом посте... 3. Но... Если бряк установлен на 01194C28 - далее два раза F7. Дизассемблер мейн треда по адресу 00129258 имеет вид: Код (Text): 00129258 40 INC EAX 00129259 8B1C24 MOV EBX,DWORD PTR SS:[ESP] 0012925C F9 STC 0012925D 00F3 ADD BL,DH 0012925F A5 MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ES> 00129260 15 53A6F2FE ADC EAX,FEF2A653 00129265 05 18371500 ADD EAX,153718 0012926A F0:F2: LOCK PREFIX REPNE: ; LOCK prefix is not allowed 0012926C 43 INC EBX 0012926D 51 PUSH ECX 0012926E 7B D0 JPO SHORT 00129240 00129270 198D 4DA5E8FF SBB DWORD PTR SS:[EBP+FFE8A54D],ECX 00129276 AF SCAS DWORD PTR ES:[EDI] 00129277 7E 1A JLE SHORT 00129293 00129279 B6 38 MOV DH,38 0012927B 64:F4 HLT ; Privileged command 0012927D 04 4B ADD AL,4B 0012927F A5 MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ES> 00129280 15 00F05942 ADC EAX,4259F000 00129285 AC LODS BYTE PTR DS:[ESI] 00129286 A6 CMPS BYTE PTR DS:[ESI],BYTE PTR ES:[EDI] 00129287 F5 CMC 00129288 46 INC ESI 00129289 51 PUSH ECX 0012928A 7B 66 JPO SHORT 001292F2 0012928C FD STD 0012928D D5 0F AAD 0F 0012928F 5A POP EDX 00129290 EA 5A7B569E CAD>JMP FAR DBCA:9E567B5A ; Far jump 00129297 6E OUTS DX,BYTE PTR ES:[EDI] ; I/O command 00129298 FD STD 00129299 1D F0A515E8 SBB EAX,E815A5F0 0012929E 81D2 15000989 ADC EDX,89090015 001292A4 4D DEC EBP 001292A5 5E POP ESI 001292A6 F2:67: PREFIX REPNE: ; Superfluous prefix 001292A8 BF 43B20B4D MOV EDI,4D0BB243 001292AD 59 POP ECX 001292AE AE SCAS BYTE PTR ES:[EDI] 001292AF FA CLI 001292B0 EA 75F85AC5 833>JMP FAR 3483:C55AF875 ; Far jump 001292B7 A1 FE474A86 MOV EAX,DWORD PTR DS:[864A47FE] 001292BC 85AB 8520D574 TEST DWORD PTR DS:[EBX+74D52085],EBP 001292C2 FFF3 PUSH EBX 001292C4 44 INC ESP 001292C5 8BA7 F9E58BB8 MOV ESP,DWORD PTR DS:[EDI+B88BE5F9] 001292CB 3A16 CMP DL,BYTE PTR DS:[ESI] 001292CD 0050 D2 ADD BYTE PTR DS:[EAX-2E],DL 001292D0 4C DEC ESP 001292D1 5E POP ESI 001292D2 93 XCHG EAX,EBX 001292D3 7E 27 JLE SHORT 001292FC 001292D5 C2 023A RETN 3A02 В этом коде встречаются не менее бессмысленные "конструкции" вроде Код (Text): 0012926A F0:F2: LOCK PREFIX REPNE: ; LOCK prefix is not allowed , на которых трассировка тоже падает. Объясните мне, бога ради, если это ваще поддается объяснению, как установка точки бряка влияет на дезассемблирование кода?! И как с этим быть?
Исследую приложение с OllyDbg. При работе приложения область стека начиная с адреса 0х00129258 динамически заполняется двойными словами, после чего на 0х00129258 передается управление. Во время работы этой функции по адресу 0х001296D0 заносится константа 0x00000FB9. Моя проблема - установить условное прерывание, чтобы выяснить, где именно это происходит. Трассировка не помогает. Вероятно, срабатывает антиотладка, и либо приложение падает в исключение и завершение процесса, либо дезассемблер "лепит горбатого"... Все, что завязано на INT3 - не проходит... Как правильно написать выражение для условия прерывания?
Если я правильно понял, то в этом случае можно попробовать аппаратную точку останова на запись в эту область памяти.
Это стек. Если ставить hardware на write на блок в стеке, - фиг я доберусь до места. Имхо прерываться станет постоянно. Хотя, если считать, что трассировка этой функции невозможна - это уже можно считать решением... Завтра попробую, спасибо! Но я-то хотел обычное условие типа "[1296D0] == FB9"... Пробовал уже - нет прерывания.
Tihon Стек это особая область памяти, которая активно юзается ядром. Есть множество событий, при которых ядро пишет в стек. А в ядре хардварные регистры имеют ядерные брейки, эта регистровая часть состояния задачи переключается при трап-процессинге, поэтому пользовательский брейк при доступе к памяти из ядра не сработает. Также менеджер памяти не позволит использовать сторожевые страницы, так как сам использует этот механизм для расширения стека.
Еще раз спасибо... Сегодня поставил хардверное прерывание на запись в стек. В самом деле, - обычной трассировкой ничего путного не получается - я говорил. А с хардверным прерыванием просто замечательно имитируется трассировка стековой области. Правда, ничего конкретного не достиг, потому как пройти бесконечные вложенные циклы просто не хватило времени. Но метод в самом деле хорош!
Поставил я хардверное прерывание на стек, - и сижу, тупо "жмя" на F9, и наблюдая за статусной строкой OllyDbg... И так вот часами Но в принципе процесс можно автоматизировать. Вот как это может выглядеть. Поверх запущенной Ольки работает приложение, которое считывает текст из ее "статусной" строки (серое окно в нижней части). Задаем адрес в стеке, который нужно поймать. Приложение симулирует нажатие кнопки F9, и считывает из статусной строки адрес бряка. Пока не достигнуто контрольное значение адреса - процесс повторяется... Казалось, ничего серьезного, просто API. Но сама Олька при рассмотрении ее окон оказалась совсем не проста. Главная проблема - что "статусное окно", которое надо контролировать, - нижняя часть общего большого окна класса OllyDbg (?!). И как из него брать текст - не имею понятия. Помогите советом, - расскажите про Ольку. Как подступиться к этому нижнему серому окну через API?