Не могу понять, либо я сошел с ума, либо компилятор, которым клепали программу, дизассемблируемую мной. По всему тексту программы напихан код, вызывающий определенную функцию в случае провала проверки на допустимость каких-либо значений (границы массивов там, диапазоны значений в таблицах switch-case, нулевые указатели перед их разадресацией или просто значения, которые никак не должны быть в текущей ситуации). что-то типа такого: Code (Text): test edi,edi jnz qwer push 0F6h push 0Bh call TraceError add esp, 8 qwer: mov eax,[edi] Саму TraceError не привожу, но суть там сразу видно - она в зависимости от состояния глобальной переменной либо вызывает прерывание отладчика либо выводит сообщение об невозможности продолжения выполнения программы. В любом случае вызов этой функции - ненормальная ситуация, которая вообще не должна возникать если в проге все в порядке. С этим все понятно, самоконтроль программы - дело нужное. Но вот это я вообще понять не могу: Code (Text): .text:1006ADF9 mov al, byte ptr [esi+Element.field_330] .text:1006ADFF test al, 2 .text:1006AE01 jz short loc_1006AE1F .text:1006AE03 test al, 2 .text:1006AE05 jnz short loc_1006AE16 .text:1006AE07 push 105h .text:1006AE0C push 0Bh .text:1006AE0E call TraceError .text:1006AE13 add esp, 8 .text:1006AE16 .text:1006AE16 loc_1006AE16: ; CODE XREF: UpdateCtrl+15j .text:1006AE16 test byte ptr [esi+Element.field_330], 1 .text:1006AE1D jz short loc_1006AE2E .text:1006AE1F .text:1006AE1F loc_1006AE1F: ; CODE XREF: UpdateCtrl+11j .text:1006AE1F push 53Eh .text:1006AE24 push 19h .text:1006AE26 call TraceError .text:1006AE2B add esp, 8 .text:1006AE2E .text:1006AE2E loc_1006AE2E: ; CODE XREF: UpdateCtrl+2Dj .text:1006AE2E test byte ptr [esi+Element.field_330], 2 .text:1006AE35 jnz short loc_1006AE46 .text:1006AE37 push 0F6h .text:1006AE3C push 0Bh .text:1006AE3E call TraceError .text:1006AE43 add esp, 8 .text:1006AE46 .text:1006AE46 loc_1006AE46: ; CODE XREF: UpdateCtrl+45j .text:1006AE46 test byte ptr [esi+Element.field_330], 1 .text:1006AE4D mov eax, [esi+Element.ptrOrigValue] .text:1006AE53 jnz short loc_1006AE60 .text:1006AE55 test eax, eax .text:1006AE57 jnz short loc_1006AE76 .text:1006AE59 push 0F9h .text:1006AE5E jmp short loc_1006AE6C .text:1006AE60 ; --------------------------------------------------------------------------- .text:1006AE60 .text:1006AE60 loc_1006AE60: ; CODE XREF: UpdateCtrl+63j .text:1006AE60 cmp eax, 81h .text:1006AE65 jnz short loc_1006AE76 .text:1006AE67 push 0FDh .text:1006AE6C .text:1006AE6C loc_1006AE6C: ; CODE XREF: UpdateCtrl+6Ej .text:1006AE6C push 0Bh .text:1006AE6E call TraceError .text:1006AE73 add esp, 8 .text:1006AE76 .text:1006AE76 loc_1006AE76: ; CODE XREF: UpdateCtrl+67j .text:1006AE76 ; UpdateCtrl+75j Суть - весь этот код сплошные вызовы вызовы TraceError, но прикол в том, что он одни и те же вещи проверяет многократно, причем аж умудрился проверить дважды "test al, 2" чуть ли не подряд (.text:1006ADFF). Зачем он это делает? Это у компилятора паранойя случилась или я чего-то не понимаю? Можно ли как то опознать компилятор по этим вызовам (если, например, такой вызов отладки униккален для какого-то компилятора)?
Ни разу не сталкивался с подобным. Может это антиотладка? или просто мусорный код, чтобы отвлечь твое внимание и напугать тебя? Много полезного не скажу, но что говорит peid(или аналоги)? Впрочем, ты наверное догадался посмотреть, и там "Nothing found *" Известные мне способы узнать компилятор: - глянуть размер файла. для асма несколько килобайт. для delphi 300кб и более. - открой редактором ресурсов(ResHack) exe-шник. если есть RCData, то Borland - поищи такие referenced text string: borland, microsoft - глянь к каким библиотекам обращается
Ага, эта версия кажется наиболее правдоподобной (правда непонятно, почему автор не отключил дебаг, прога та сильно критичная и прожорливая в плане процессорного времени). Но вот это все равно остается непонятным, как такое компилятор мог сваять: Code (Text): .text:1006ADFF test al, 2 .text:1006AE01 jz short loc_1006AE1F .text:1006AE03 test al, 2 Сразу вспоминается анекдот про два jmp подряд, на случай, если первый не сработает Собственно, вопрос задал с той целью, что хочу это место зачистить и использовать под нужды патчинга, поскольку в конце сгмента кода места тоже не очень много, а поправить много хочется. Изменять PE-заголовок пока не умею. Или проще научиться модифицировать PE и не возиться с подобными зачистками? Профессиональным хакерством заниматься не собираюсь, у меня просто возникла острая необходимость кое-что изменить в имеющемся софте.
2Dmitry_Milk На всякий случай посмотри нет ли jampов куда нибудь на средину инструкции недавно с таким сталкивался и исследуемый код был примерно такого же "качества" и кстати что за прога? Также код может быть закриптован что вероятнее, точнее по отрывку не скажешь
А, все спасибо, уже разобрался. Все таки это были проверки. Убрал безболезненно. http://www.mtu-net.ru/syncmodular/ , исследую sm.dll, собственно, там вся логика.
