Помогите с лодырем

Сейчас на форуме: igorcauret, Rio (+6 невидимых)

Посл.ответ	Сообщение
zds Ранг: 57.0 (постоянный), 10thx Активность: 0.05↗0.08 Статус: Участник	Создано: 15 ноября 2014 00:41 · Личное сообщение · #1 Занимаюсь прогой с защитой Sentinel SuperPro чтобы уйти от эмуляторов скопировал дамп ключа непосредственно в dll и перенаправил чтение в функции RNBOsproRead из этого дампа. сохранил все изменения через Ольку. Все работает прекрасно. Но появилась нужда сделать лоадер для этого дела. Взял заранее рабочий проект лоадера (который прекрасно работал с предыдущими програми), но здесь появилась первая загвоздка - просто WriteProcessMemory не прокатывает, т.к. память защищена. Добавил VirtualProtectEx - все заработало. вот кусок непосредственно записи: Code: VirtualProtectEx(pi.hProcess,Pointer(textadr+$4e60), $22, PAGE_READWRITE, y); // y=32 WriteProcessMemory(pi.hProcess, Pointer(textadr+$4e60), @NText1, $22, bytesread); VirtualProtectEx(pi.hProcess,Pointer(textadr+$4e60), $22, y, nil); Но после этого програма падает. Смотрел через Ольку - изменения применяются правильно. Но при первом же обращении к этой dll на первой же команде (функция вообще не подвергалась изменению) Олька выдает "access violation when executing...", а затем прога аварийно завершается "terminated C0000005". Память меняю в секциях rdata и text Подскажите пожалуйста в чем может быть мой косяк?

Apocalypse Ранг: 88.2 (постоянный), 111thx Активность: 0.07↘0.01 Статус: Участник	Создано: 15 ноября 2014 00:57 · Поправил: Apocalypse · Личное сообщение · #2 WriteProcessMemory сам по себе вызывает ZwProtectVirtualMemory, т.ч врятли нужно VirtualProtectEx Ну и: Code: VirtualProtectEx(pi.hProcess,Pointer(textadr+$4e60), $22, PAGE_READWRITE, @y); \| Сообщение посчитали полезным: zds
UniSoft Ранг: 52.0 (постоянный), 146thx Активность: 0.03↗0.08 Статус: Участник	Создано: 15 ноября 2014 00:58 · Личное сообщение · #3 zdszds пишет: Подскажите пожалуйста в чем может быть мой косяк? сразу скажу, что с Delphi я не дружу, но по логике вот тут Code: VirtualProtectEx(pi.hProcess,Pointer(textadr+$4e60), $22, PAGE_READWRITE, y); по моему должно быть Code: VirtualProtectEx(pi.hProcess,Pointer(textadr+$4e60), $22, PAGE_READWRITE, @y); пятый аргумент функции является указателем на DWORD, который получит текущее значение флагов защиты, а в вашем случае получается, что вы туда передаете содержимое y, а оно скорее всего неверное. \| Сообщение посчитали полезным: zds
Hellspawn Ранг: 990.2 (! ! !), 380thx Активность: 0.68↘0 Статус: Модератор Author of DiE	Создано: 15 ноября 2014 01:07 · Личное сообщение · #4 права обратно не возвращаются на память: VirtualProtectEx(pi.hProcess,Pointer(textadr+$4e60), $22, y, y); lpflOldProtect [out] A pointer to a variable that receives the previous access protection of the first page in the specified region of pages. If this parameter is NULL or does not point to a valid variable, the function fails. ----- [nice coder and reverser] \| Сообщение посчитали полезным: zds
zds Ранг: 57.0 (постоянный), 10thx Активность: 0.05↗0.08 Статус: Участник	Создано: 15 ноября 2014 01:56 · Поправил: zds · Личное сообщение · #5 Всем спасибо. То что надо. В очередной раз трачу целый день из-за невнимательности и одного знака. Code: VirtualProtectEx(pi.hProcess,Pointer(textadr+$4e60), $22, PAGE_READWRITE, @y); WriteProcessMemory(pi.hProcess, Pointer(textadr+$4e60), @NText1, $22, bytesread); VirtualProtectEx(pi.hProcess,Pointer(textadr+$4e60), $22, y, @y) Apocalypse, просто WriteProcessMemory с предыдущими прогами все работало. Здесь чтение проходит, а запись выдает ошибку 998 кажется. VirtualProtectEx решает проблему.
Archer Ранг: 2014.5 (!!!!), 1278thx Активность: 1.34↘0.25 Статус: Модератор retired	Создано: 15 ноября 2014 10:35 · Личное сообщение · #6 Стоит отметить, что хреново ставить PAGE_READWRITE для секции кода. Если код после смены прав, но до возвращения прав на место, начнёт исполняться на этой странице, оно свалится на DEP. Execute добавь. \| Сообщение посчитали полезным: Kindly, zds, UniSoft
dosprog Ранг: 431.7 (мудрец), 391thx Активность: 0.73↘0.32 Статус: Участник	Создано: 16 ноября 2014 10:01 · Поправил: dosprog · Личное сообщение · #7 Господа, доброго времени суток. Тоже касаемо лоадеров, чтоб не плодить темы, задам вопрос тут. ТС, прошу прощения за оффтоп. Я понимаю, что это не форум программистов, но может быть кто-то натолкнёт на мысль. Проблема (если так можно сказать) с консольными приложениями. Смысл таков: Консольное приложение (первое, лоадер) запускает (с помощью CreateProcess) другое консольное приложение (второе, хм,"поцеент"). Оба скомпилированы как консольные. Первое (лоадер) работает нормально, ввод_с_клавиатуры и вывод_на_экран без вопросов. Зато второе работает (более/менее работает, но меня такое не устраивает) - только если процесс для него создаётся с флагом CREATE_NEW_CONSOLE. При этом да, создаётся новая консоль и там у второго приложения нормально работает ввод/вывод. По завершении второго приложения эта его новая консоль автоматически закрывается. Если же процесс для второго приложения создаётся с флагом DETACHED_PROCESS (т.е. оно может само выделять для себя консоль), тогда никакой новой консоли не создаётся (это второе приложение запрашивает консоль, получает 0 - типа, у него уже есть консоль, родительская) и никакой ввод/вывод у второго приложения не работает. Система ошибок не выдаёт, второе приложение просто отрабатывает втихую и завершается. То же самое происходит, если не задавать вообще никаких "консольных флагов" при создании процесса для второго приложения. Мне же нужно, чтобы второе приложение работало (ввод/вывод) с первой, родительской консолью. Поскольку созданная новая клиентская консоль (второго приложения) тут же по завершении второго приложения закрывается и даже не даёт прочесть, что там вывела эта вторая программа, например, сообщения об ошибках, если они были. Это не годится. Вот такая проблема. Причём если второе приложение GUIёвое, то вообще не возникает никаких вопросов. Вопросы только к запускаемому (второму) приложению консольного типа. - Оно не хочет работать с родительской консолью как положено. Заморачиваться не нужно, как-нибудь выкручусь, но может кто-то сталкивался с такой фичей и сможет натолкнуть на решение...
Archer Ранг: 2014.5 (!!!!), 1278thx Активность: 1.34↘0.25 Статус: Модератор retired	Создано: 16 ноября 2014 10:33 · Личное сообщение · #8 dosprog Когда 2 процесса делят консоль, особо кошерной работы ожидать и не стоит. By default, a console process inherits its parent's console, and there is no guarantee that input is received by the process for which it was intended. Так что либо сваргань ему отдельную консоль, либо поиграйся с хендлами hStdInput/hStdOutput/hStdError в STARTUPINFO. \| Сообщение посчитали полезным: dosprog
dosprog Ранг: 431.7 (мудрец), 391thx Активность: 0.73↘0.32 Статус: Участник	Создано: 16 ноября 2014 10:57 · Поправил: dosprog · Личное сообщение · #9 Archer, жаль. Что ж, я экспериментально пришёл к тому же мнению, что там лажа полная. Попробую воспользоваться советом о STARTUPINFO. В смысле, передать туда хэндлы, полученные родителем для своей консоли. --добавлено-- Попробовал. Разницы при всех вариантах не заметил. Такое впечатление, что те поля в STARTUPINFO вообще не учитываются. Жаль. Остаётся использовать только отдельную консоль и мириться с её закрытием по окончании работы второй программы. Паршиво, что и перенаправление в файл работает только для лоадера, от клиента никаких следов в том файле не остаётся. Даже если для него создаётся отдельная консоль. Если не создаётся - то же самое. [flame mode on] ..а эти говнюки делают блин трёхменые "рабочие столы", вместо того, чтобы сопли подобрать в системе.. [flame mode off]
Archer Ранг: 2014.5 (!!!!), 1278thx Активность: 1.34↘0.25 Статус: Модератор retired	Создано: 16 ноября 2014 12:23 · Личное сообщение · #10 dosprog пишет: Такое впечатление, что те поля в STARTUPINFO вообще не учитываются А точно всё правильно сделал-то? Не забыл флаг STARTF_USESTDHANDLES+the handles must be inheritable and the function's bInheritHandles parameter must be set to TRUE? Ибо эти вещи для редиректа консоли в пайп или ещё куда юзаются прилично где и вполне работают.
dosprog Ранг: 431.7 (мудрец), 391thx Активность: 0.73↘0.32 Статус: Участник	Создано: 16 ноября 2014 12:29 · Поправил: dosprog · Личное сообщение · #11 Спасибо, проверю. Собственно, редирект в файл это как выход годится только наполовину. Хотя, может, это и ))бОльшая половина. --добавлено-- Проверил. Реакция на включение fInheritHandles имеется. На экране всё как и прежде, а при перенавлении вывода в файл на выходе пустой файл (нулевой длины). То-есть, уже и от лоадера сообщения туда не попали. Вот код. Code: mov eax, STARTF_USESTDHANDLES mov sinf.dwFlags,eax mov eax,stdin_handle mov sinf.hSin,eax mov eax,stdout_handle mov sinf.hSou,eax mov eax,stderr_handle mov sinf.hErr,eax xor eax,eax or eax,CREATE_SUSPENDED or eax,CREATE_NEW_CONSOLE push o hProcess ; lpProcessInformation push o sinf ; lpStartupInfo push 0 ; lpCurrentDirectory push 0 ; lpEnvironment push EAX ; dwCreationFlags push 1 ; bInheritHandles push 0 ; lpThreadAttributes push 0 ; lpProcessAttributes push pArguments ; lpCommandLine push o proсess_full_path ; lpApplicationName call CreateProcessA Просто новый процесс (вообще постороний файл) будет получать эти хэндлы не извлекая из STARTUPINFO (после вызова GetStartupInfo() ), а запрашивая новые, и нужно ещё проверить, даст ли ему система те, что переданы родителем. Даже если и даст те же, .. в общем, вопросы. Покручу ещё так и эдак все варианты..

Для печати