Semiono А зачем Вы подключаете shell32.inc, если я дал нормальное описание импорта, содержащего необходимую функцию? Не всегда в инклудах есть необходимые функции. Аналогично. Зачем цеплять, если весь необходимый импорт уже описан? Хочется чего-то ещё, дописывайте по аналогии директорию импорта (список ф-ий между data import и end data).
Ну теперь и я убедился, что лучше самому всё указывать! Однако обидно за дистрибутив, то что они не доводят до ума инклюды, или это не так просто как кажется? (среди всех win32 versions) Я просто хотел затестировать инклюд, ну вот и выяснил что лажа. Правда есть ещё pcount и equates, непонятного предназначения... это понятно, хотя я думал такие функции в win32wx.inc должны быть? Хотя я что-то слышал, типа это линки для совместимости ядра... типа в ascii версиях имена unicode... Лучше об этом не задумываится, всёравно темень!
Да, большинство функций SomeApiA это обёртки над SomeApiW. Они просто преобразуют параметры в юникод и вызывают W функцию. Но это не тот случай. CommandLineToArgvA нету вообще, только юникод версия.
Semiono Никто не говорил, что это лучше. По большому счёту я бы даже сказал, что это не очень удобно: каждый раз описывать весь используемый импорт. Но это моё предпочтение, поэтому и описал отдельно... для наглядности. А вот в кучу смешивать, разумеется, не нужно. Если Вы засунули в импорт include '%fasm%\api\kernel32.inc', то будьте добры не объявляйте те же самые метки повторно. Это элементарно просто. Хотите, пополните. Можно написать довольно простой парсер экспорта произвольной dll, который будет строить соответствующую инклуду одним щелчком мыши. Почему в инклудах не все функции, не знаю... автору захотелось так. Вы бы заглянули в win32wx.inc да посмотрели, что там есть. Реальное описание всех меток для апи-функций находится только в соответствующей инклуде типа kernel32.inc или user32.inc и т.п. независимо от того, Unicode-версия Вам нужна или ASCII. После подключения оных явно или неявно (через инклуды с суффиксом x) Вы можете использовать любые указанные там апи. А вот во что будет раскрываться какой-нибудь GetCommandLine — в GetCommandLineA или в GetCommandLineW — определяется тем, какую инклуду Вы подключили для раскрытия макроса "api": win32a.inc или win32w.inc.
Всё, я теперь гуру! =) Код (Text): include '%fasm%\win32ax.inc' entry start section '.rsrc' resource data executable readable writeable directory RT_ICON,icons,RT_GROUP_ICON,group_icons,RT_VERSION,versions resource icons,\ 1,LANG_NEUTRAL,icon_data1,\ 2,LANG_NEUTRAL,icon_data2,\ 3,LANG_NEUTRAL,icon_data3,\ 4,LANG_NEUTRAL,icon_data4 resource group_icons,17,LANG_NEUTRAL,main_icon resource versions,1,LANG_NEUTRAL,version icon main_icon,\ icon_data1,'%icons%\16x16.ico',\ icon_data2,'%icons%\32x32.ico',\ icon_data3,'%icons%\48x48.ico',\ icon_data4,'%icons%\64x64.ico' versioninfo version,VOS__WINDOWS32,VFT_APP,VFT2_UNKNOWN,LANG_ENGLISH+SUBLANG_DEFAULT,0,\ 'FileDescription','psskill...',\ 'LegalCopyright','2001-2005 GmbH',\ 'FileVersion','1.0.0.0',\ 'ProductVersion','1.0.0.0',\ 'OriginalFilename','psskill.exe',\ 'Company','msdn' start: ; l_inc invoke GetCommandLine invoke CommandLineToArgv,eax,argsNum cmp dword[argsNum],1 push eax jbe @F ; jump_if_below_or_equal push dword[eax+4] call AdjustMyToken stdcall findProcessID test eax,eax ; _\|/_ jz @F ; _\|/_ invoke OpenProcess,PROCESS_TERMINATE,FALSE,eax push eax invoke TerminateProcess,eax,1 invoke CloseHandle jmp start ; _\|/_ @@: ; invoke LocalFree invoke ExitProcess,0 ret argsNum dd ? section '.idata' import data executable readable writeable library advapi32,'ADVAPI32.dll',kernel32,'KERNEL32.DLL',shell32,'SHELL32.DLL' include '%fasm%\api\advapi32.inc' import kernel32,OpenProcess,'OpenProcess',\ TerminateProcess,'TerminateProcess',\ CloseHandle,'CloseHandle',\ lstrcmpi,'lstrcmpiW',\ CreateToolhelp32Snapshot,'CreateToolhelp32Snapshot',\ Process32First,'Process32FirstW',\ Process32Next,'Process32NextW',\ GetCommandLine,'GetCommandLineW',\ LocalFree,'LocalFree',ExitProcess,'ExitProcess' import shell32,CommandLineToArgv,'CommandLineToArgvW' TOKEN_ADJUST_PRIVILEGES equ 20h TOKEN_QUERY equ 8h SE_PRIVILEGE_ENABLED equ 2h AdjustMyToken: invoke LookupPrivilegeValue,emptyStr,privName,tokenPriv.LUID1 mov dword[tokenPriv.PrivilegeCount],1h mov dword[tokenPriv.Attributes],SE_PRIVILEGE_ENABLED invoke OpenProcessToken,-1,TOKEN_ADJUST_PRIVILEGES OR TOKEN_QUERY,hToken invoke AdjustTokenPrivileges,[hToken],FALSE,tokenPriv,0,0,0 invoke CloseHandle,[hToken] ret emptyStr db '',0 privName db 'SeDebugPrivilege',0 struct TOKEN_PRIVILEGES PrivilegeCount dd ? LUID1 dd ? LUID2 dd ? Attributes dd ? ends hToken dd ? TH32CS_SNAPPROCESS equ 2 findProcessID: ; takes one parameter through stack: pointer to the process name push ebp invoke CreateToolhelp32Snapshot,TH32CS_SNAPPROCESS,0 mov ebp,eax mov dword[procEntry.dwSize],sizeof.PROCESSENTRY32W invoke Process32First,eax,procEntry @@: invoke Process32Next,ebp,procEntry test eax,eax jz @F invoke lstrcmpi,procEntry.szExeFile,dword[esp+8] test eax,eax jnz @B mov eax,dword[procEntry.th32ProcessID] @@: pop ebp retn 4 struct PROCESSENTRY32W dwSize dd ? cntUsage dd ? th32ProcessID dd ? th32DefaultHeapID dd ? th32ModuleID dd ? cntThreads dd ? th32ParentProcessID dd ? pcPriClassBase dd ? dwFlags dd ? szExeFile dw MAX_PATH dup (?) ends tokenPriv TOKEN_PRIVILEGES <> procEntry PROCESSENTRY32W <> align 4 самый баг был в том, что ExitProcess отсутствовало, я ж понадеялся что LocalFree закрывает всё корректно, и когда вылетало memory could not be "read" я думал у меня цикл кривой получается, и так по кругу пару ночей! старый добрый ExitProcess, 0 я ж его ещё когда очень-первые шаги делал именно на таком ерроре выхватил, а тут же знал но тупил но парни, может оптимизировать ещё больше можно чёнитьбудь? моджед есть покрасивше вариант?
Что такое треды? Каково практическое их применение? invoke Threads32First или даже invoke Heap32First можно ли так убить процесс? если нет то нафига они нужны?
Действительно, кому нужны операции, не приводящие к смерти хотя бы одного процесса... CreateRemoteThread(CalcProcessHandle, 0, 0, address_of_ExitProcess, 0, 0, 0);
Semiono То, что Вы сделали с моим кодом, — это ужасно. Одними замечаниями тут трудно ограничиться, т.к. код превратился в бессмысленную кашу. Поэтому отвечу только на русскую часть сообщения. +1 Самый баг в том, что Вы так решили. Одного ret вполне достаточно при условии правильности остального кода. В оригинале LocalFree освобождал память под распарсенные с помощью CommandLineToArgv аргументы. Причём LocalFree принимал параметр, переданный через расположенную перед jbe @F инструкцию push eax. Теперь параметр передаётся, а функция не вызывается. "Выяснилось", я полагаю, ещё до завершения "укурки". Главное что "некрасивше" вариант вряд ли найдётся.
l_inc, я не хотел Ваш код испортить! Я хотел только, добиться решения проблеммы. Но а как я это делаю, я по другому не могу, что я виноват чтоли! То что я секции двигал, это ради собственного познавательного процесса, но сам код я почти не трогал, там всё Вами написано, за исключением моих "ежей" ))) Ещё Вы правы, насколько я понимаю, надо в процедуре findProcessID крутиться, ибо у меня получается наверное, что снапшёт создаётся многократно, что плохо. Я попытаюсь это исправить. Просто я так рад был когда получилось! Две ночи сидел и всё без толку, я же методом тыка практически кодю ))) (это мне заменяет укурку) Но благодаря этой программе я много пользы извлёк, хотяб я теперь твёрдо знаю анонимные джампы, раньше теоретически это до меня не доходило почему-то. Кстати, там размер файла варьировался от 85 504 bytes до 86016 bytes в зависимости от размещения данных. Ну я согласен, это в моей интерпретации ошибка.
Semiono Ну Вы в общем исправляйте до максимально приемлемого вида, где нету многократного создания снимков и взятия/парсинга командной строки (которые теперь странным образом тоже выполняются в цикле), нету бессмысленных прыжков между столь же бессмысленными секциями, нету стрёмных ресурсов со строками вида "2001-2005 GmbH" и висячего align 4, утратившего свой смысл после отсылки на край исходника. Ну в общем когда в конце-концов размер файла будет варьироваться не "от 85 504 bytes до 86016 bytes", а между 1 024 и 1 536 байт, тогда выкладывайте, что получилось.
OllyDebug - я знаю, но пока мне очень тяжело. Кроме статей введения в крекинг не знаю что почитать...
Semiono По-моему этих статей более, чем достаточно. Причём для понимания основных концепций работы с отладчиком первых 15-ти вполне хватит. Тем более для отладки собственных программ на асме.
Одну мысль скажу пока не забыл. Понятное дело, что новичку тем более не следует начинать с этого, ну и вообщем кашеобразный код не есть хорошо! Однако, сиё существует, и как бы поразмыслить, какие нить хакеры наверняка используют такое чтоб запутать других Кароче, былоб не плохо в этом разбираться как-то! Я допустим загрузив в ольку свой бинарь нифига там не понимаю... у меня ж нет секций кода и данных. Написал бы какой нибудь Рикардо Нарваха на эту тему разъяснения!?
Semiono Эм... вообще-то есть, если они были в исходнике. И они видны в окне "M" (Memory map) для каждого образа, загруженного в АП процесса. К тому же после загрузки в Olly отображаемый код практически идентичен коду в исходнике за исключением имён меток (которые, кстати, можно назначить самостоятельно прямо в Olly). Соответствено неясно, какие именно разъяснения Вам нужны. Все действительно необходимые разъяснения присутствуют в вышеупомянутых статьях.
А можно получить ввод с консоли и исполнить его? Типа такого, хотя это разумеетс неправильно Код (Text): start: invoke GetCommandLine invoke CommandLineToArgv,eax,argsNum [argsNum] это не имеет отношения к (ProcessClose), это я просто другое задумал... вообщем Zen =) ??? как чёнибудь исполнить? или в код нельзя впринцыпе водставить ввод?