Binary digit, wasm`овцы. Вчера открыл "Поиск адресов Api в win95-XP" by [c] Sars. сразу бросился в глаза код поиска базы кернела, именно эту задачу мне и надо решить: _ReadSEH: xor edx,edx mov eax,fs:[edx] ; bad command dec edx _SearchK32: cmp [eax],edx je _CheckK32 mov eax,dword [eax] ; и здесь, где "ptr"? jmp _SearchK32 _CheckK32: mov eax,[eax+4] xor ax,ax Помеченая в комментарии команда у меня не сработала, приш- лось заменить на push fs,pop es и адресоваться mov eax,es:[edx]. Делал в masm32 v8.0, w2k sp4 Теперь же набацал следующий код для проверки на 'MZ','PE': cmp word ptr[eax],'ZM' jne exit mov edi,[eax+ei_e_lfanew] cmp word ptr[edi],'EP' ; ошибка доступа jne exit Здесь Олли дает: Acess violation when reading [000000c8] - use shift/F7/F8/F9 to pass exception to programm. Вопрос каким макаром можно проверить на сигнатуры не вызывая ошибок? К тому же если копаться в заголовке в поисках функции, то блин опять таки можно вызвать ошибку доступа и какже скажите пожалуйста найти функ- ции в кернеле? ЗЫ: Мне не доконца понятен код поиска базы, может кто объяснит?
Насколько я помню, Сарс писал ту стотью под тасм. Там вроде как адресация не такая как в масме (не уверен, т.к. с тасмом работал очень мало и уже все забыл). Под чутким руководством автора я в свое время успешно написал сей код на фасме и все было хорошо. Насчет проверки сигнатур: Код (Text): @@: ; search for 'MZ' cmp word [eax],'MZ' je @F sub eax,10000h ; 64K back jmp @B @@: ; search for 'PE' mov edx,[eax+3Ch] cmp word [eax+edx],'PE' je search_APIs ; goto API search jmp vx_end ; it's NOT PE-module Это фасм, но суть должна быть понятна. А у тебя в коде mov edi,[eax+ei_e_lfanew] cmp word ptr[edi],'EP' ошибка такая: в edi ты пихаешь значение из поля lfanew. Это верно. Ну а кто будет к этому значению адрес модуля прибавлять? Там же смещение ОТНОСИТЕЛЬНО начала модуля. Вот эотт адрес начала модуля и надо присобачить. Смотри мой код. Поиск базы кернела, как ты мог догадаться идет по seh. Плюшка в том, что в структуре seh всегда есть функция из кернела. В этой части у меня с теорией туго, так что принимаем это за данное. Но судя по коду можно сказать следующее: если по адресу fs:[0] лежит -1, то это наш клиент. Значит рядом с этой -1 лежит адрес функции из кернела (какой - я не знаю). А иначе ищем дальше, пока не найдем -1. Видимо, структура seh представляет из себя нечто вроде списка: struct S { S *pNext; void *pAddress; } Вот когда pNext == -1, значит мы в хвосте списка. Но точно я не уверен, т.к. вобще не знаю что такое seh, так что кому не в лом - просвятите. Собсно, все.
вот и я о том же, что одно дело получается а другое почему? Я даже незнаю че такое это SEH? А ты говоришь ищем по нему! Жду вот говорят будет перевод статьи по этому поводу, но пока глухо. Кому не влом пожалуйста опишите!
IceStudent И знаешь че там написано? Не поверишь. За доп. информацией обратитесь к Джереми Гордону, и знаешь такая же отписка в большинстве литературы. Напоминает контрольную в школе один решил, и все ... Володя старался, за что и почет ему, но и у него много отписок на инфу, где опять таки начинающих не хотят замечать!
"10. SEH с точки зрения кракера" Там описывается структура SEH, а также то, что последним (или первым, смотря как посмотреть) узлом является функция kernel32.dll UnhandledExceptionFilter. Потом, на форуме не раз обсуждали, что такое SEH и как его применять. Ну и наконец, литература, о которой говорил Володя в статье, — почему бы не почитать её?
IceStudent Хе-хе.. Это круто, конечно, но у меня нет времени даже "упаковщики" прочитать (хотя порывался раз 20 уже..), а ты говоришь... Сессия все-таки приближается..
n0p Ну вот смотри, я обычно использую приблизительно такой код: Код (Text): mov edi, BaseOfImage assume edi:ptr IMAGE_DOS_HEADER .IF [edi].e_magic == IMAGE_DOS_SIGNATURE add edi, [edi].e_lfanew assume edi:ptr IMAGE_NT_HEADERS .IF [edi].Signature == IMAGE_NT_SIGNATURE inc ValidPE ; mov ValidPE, TRUE .ENDIF .ENDIF А теперь посмотри структуру IMAGE_NT_HEADERS, в ней на член Signature(DWORD), который для проверки валидности я сравниваю с IMAGE_NT_SIGNATURE equ 00004550h а почему именно DWORD нужно спрашивать у M$
В MASM'е нужно писать так: assume fs:nothing mov eax,fs:[edx] С адресацией через es: в FLAT-модели CS=DS=ES=SS и не стоит это мнеять - могут возникнуть проблемы - в нашем случае, с цепочечными командами (movs,...) Хотя, если не забывать восстанавливать es - все должно работать. Сигнатура PE - это 4 баята. IMHO эту нужно для выравнивания. Замечание по поводу поиска через SEH: IMHO последняя функция в цепочке - не UnhandledExceptionFilter, а стандартный MS-обработчик __except_handler3 - экземпляр из kernel32.dll. Код типа: __try {...} __except (UnhandledExceptionFilter()) {...} приводит к тому, что в цепочку SEH добавляется вход с __except_handler3 и заводится специальная структура для __except_handler3, в которуй и запихивается указатель на UnhandledExceptionFilter.
n0p Только это спасёт тебя от позора Нет, правильнее 0x50450000, т.е. cmp dword[eax+edx],$00004550 А куда ж оно денется? Ведь вероятность, что по искомому смещению будет 54045XXXX вместо 50450000 очень мала
>а почему именно DWORD нужно спрашивать у M$ Для большей вероятности я все таки решил проверять после сигнатуры на нули, т.к. если их нет файл не выполнится.по крайней мере патчю через хью в ручную, не работает. Но люди правы вероятность ненулей слишком мала, да и кому нужно что бы были не нули? Еще вопрос если прав Били Болсебу, то если MZ поменять местами то управление сначала получит загушка. Есть ли у кого какой код, где это используется?
