Есть прога накрытая StarForce v.3.4.49.1 Сделал лоадер, тормознул на OEP, дамп, импорт и все ОК, старфос отломан. Вышла новая версия проги. Версия стара 3.4.76.0 Опять делаю лоадер, но прога на OEP не тормозитцо, а запускается. Аттачусь к проге, смотрю на OEP байты EBFEh, т.е. прога в памяти пропатчена, а не тормозится Впечатление такое, что прога проскакивает OEP до пропатчивания.
Может кто-нить че посоветует
OEP нашел 100% Прога на делфях. Вот исходник лодера
.486
.model flat, stdcall
option casemap :none

include \masm32\include\windows.inc
include \masm32\include\masm32.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc

includelib \masm32\lib\masm32.lib
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib

.data
hWnd dd 0

App db "Error",0
Err1 db "Program not found ",0
prog db "C:\Program Files\AD\AD.exe",0

bufwr DWORD 0EBh
bufwr1 DWORD 0FEh

va DWORD 0074E03Ch
va1 DWORD 0074E03Dh


.data?
bufr dw ?
pinfo PROCESS_INFORMATION <>
sinfo STARTUPINFO <>
n DWORD ?

.code

start:

invoke CreateProcess,addr prog,NULL,NULL,NULL,FALSE,NULL,NULL,NULL,addr sinfo,addr pinfo

.IF eax == 0
invoke MessageBox,NULL,addr Err1,addr App,MB_OK
invoke ExitProcess,0
.ENDIF
.WHILE TRUE
invoke ReadProcessMemory,pinfo.hProcess,va,addr bufr,1,n
.IF eax != 0
.IF bufr == 055h
invoke SuspendThread,addr pinfo.hThread
invoke WriteProcessMemory,pinfo.hProcess,va,addr bufwr,1,n
invoke WriteProcessMemory,pinfo.hProcess,va1,addr bufwr1,1,n
invoke ResumeThread,addr pinfo.hThread
invoke CloseHandle,pinfo.hThread
invoke ExitProcess,0
.ENDIF
.ENDIF
.ENDW

end start

| Сообщение посчитали полезным:

Конечно, метод не фонтан просто брать и читать. Вполне может и проскочить, ибо синхронизация вообще отсутствует как таковая. Как вариант-подними приоритет лоадера, будет чаще читать, меньше вероятность, что проскочит. А в идеале-надо ставить бряки на функи какие-нить и синхронизировать.

| Сообщение посчитали полезным:

Archer пишет:
Как вариант-подними приоритет лоадера
Как это можно реализовать. Подскажи

| Сообщение посчитали полезным:

нда, удивительно, что первый раз такое сработало. Я бы на твоем месте сделал бы перехват какой-нибудь функи (VirtualAlloc, LoadLibraryA и т.д.) а в перехвате уже проверял значение и патчил. Это конечно намного сложнее способ чем у тебя, но зато более стабильный. Я все проты таким способом и патчу.

| Сообщение посчитали полезным:

seeq пишет:
сделал бы перехват какой-нибудь функи
Если я в лоадере перехвачу API функцию, то в запускаемой проге эта ф-ия тоже будет перехвачена?
По моему нет.
С протами я тоже так поступаю т.к. там один процесс. А тут два лодырь и сама прога

| Сообщение посчитали полезным:

crc1 можетбыть глупость говорю, не знаю как на это среагирует StarForce, может стоить попробовать просто поставить бряк под отладчиком на ОЕП?

-----
StarForce и Themida ацтой!

| Сообщение посчитали полезным:

Maximus пишет:
как на это среагирует StarForce
Синим экраном

| Сообщение посчитали полезным:

crc1
Приоритет может поменять, например, виндовый taskmgr. З.Ы. Приоритет реального времени лучше не задавать.
Ясен пень, если ты лоадером похукаешь функу в СВОЁМ процессе, на процессе стара это не скажется. Хукать надо в его процессе.

| Сообщение посчитали полезным:

taskmgr'ом не получается. После следующей загрузки у лоадера снова приоритет средний. Возможно это программно реализовать?

Archer пишет:
Хукать надо в его процессе.
Научи как это сделать из лоадера. К примеру можно GetModuleHandleA

| Сообщение посчитали полезным:

crc1
На дельфиворлд было, как приоритет в своей проге поднять.

-----
iNTERNATiONAL CoDE CReW

| Сообщение посчитали полезным:

@ crc1
Странно, что у тебя в первый раз получилось.
Попробуй так, может повезет опять.
Но лучше делать по науке.

invoke SetThreadPriority,addr pinfo.hThread,THREAD_PRIORITY_LOWEST
.WHILE TRUE
invoke SuspendThread,addr pinfo.hThread
invoke ReadProcessMemory,pinfo.hProcess,va,addr bufr,1,n
.IF eax != 0
.IF bufr == 055h
invoke WriteProcessMemory,pinfo.hProcess,va,addr bufwr,1,n
invoke WriteProcessMemory,pinfo.hProcess,va1,addr bufwr1,1,n
invoke ResumeThread,addr pinfo.hThread
invoke CloseHandle,pinfo.hThread
invoke ExitProcess,0
.ENDIF
.ENDIF
invoke ResumeThread,addr pinfo.hThread
.ENDW

| Сообщение посчитали полезным:

crc1 пишет:
bufwr DWORD 0EBh
bufwr1 DWORD 0FEh

crc1 пишет:
va DWORD 0074E03Ch
va1 DWORD 0074E03Dh
+2 раза WriteProcessMemory

Че это вообще за изврат такой?

| Сообщение посчитали полезным:

crc1 пишет:
Archer пишет:
Хукать надо в его процессе.
Научи как это сделать из лоадера. К примеру можно GetModuleHandleA

присоединяюсь к вопросу

| Сообщение посчитали полезным:

Krek пишет:
Странно, что у тебя в первый раз получилось.
На версии StarForce v.3.4.49.1 получается постоянно
Krek пишет:
Попробуй так, может повезет опять.
Не тормозит

| Сообщение посчитали полезным:

Конечно, при следущей загрузке лоадера будет дефолтный приоритет. Как вариант-можешь его менять сразу из лоадера. Точного кода под рукой нет, но уверен, что гугл и дофига сайтов по программированию это знают.
Насчёт лоадеров-также кода под рукой нет, посмотри примеры других лоадеров, статейки почитай, типа статеек по трейсерам у ARTeam. Если кратко, то процесс дебажиццо фактически твоим лоадером и в нужный момент меняет память.

| Сообщение посчитали полезным:

~~ в лоадере для одной ботвы (написан на VS2005 C++) применил такой алгоритм :
читаем необходимые байты до тех пор, пока они не станут такие, какие должны быть, затем РайтПроцессМемори + плюс сразу читаем эту мемори - такая как нам надо ? ок, выход, нет - пишем опять +
после РайтПроцессМемори вызов ГетЛастЕррор для контроля + все это в консольной версии с выводом
ретурнВалуе от ГетЛастЕррора и выводом прочитанных и вписанных байтов - этакая отладка визуальная...
.... тк написана на С++ и успевает вписать - то Резум и Саспент убрал, а у тебя на дельфине, то код на
АССЕМБЛЕРЕ успее 100% !!! ... кстати, может защита проверяет участок кода и есть резон писать теда до
тех пор, пока он не пройдет через EIP ?

| Сообщение посчитали полезным:

а не пробывал запускать процес суспенденым, а не суспендить его потом?

| Сообщение посчитали полезным:

vins пишет:
а не пробывал запускать процес суспенденым, а не суспендить его потом?
...это,во-первых.

А во-вторых лучше действительно перехватывать функции в исследуемом процессе,например,ту же GetModuleHandleA.Перехватывать методом внедрения своей библиотеки,а потом из этой библиотеки сплайсить функции.Почитать можно например тут:
www.xakep.ru/post/28092/default.asp?print=true
...смотри тот раздел,что "Внедрение DLL, находящейся на диске".

Приложу исходник с моей программкой для перехвата функции GetModuleHandleA, чтобы остановиться чуть ниже OEP.Не знаю правда как это будет работать со старом,но с седьмым Securom'ом работает.В общем,смотри исходник(MASM32) и заодно потестишь


fabc_05.09.2007_CRACKLAB.rU.tgz - GetApproxOEP.rar

-----
the Power of Reversing team

| Сообщение посчитали полезным:

vins пишет:
а не пробывал запускать процес суспенденым, а не суспендить его потом?

Иногда из за не понятных бубнов writeprocessmemory веозвращает 229 ошибку по гетластэррор "Функция выполнена не полностью" если суспенденым сразу запускать.

| Сообщение посчитали полезным:

Faza если перед этем VirtualProtectEx юзать то всё будет ОК

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

Суспендить процесс сразу, результата не дал. Прга запускается
DillerInc пишет:
Приложу исходник с моей программкой
Greatest thanks
Все работает Прога тормозит сразу за вызовом GetModuleHandleA

| Сообщение посчитали полезным:

Есть похожая проблема, только с dll. Есть упакованная дллка, знаю ОЕР, как тормознуть лоадером?

| Сообщение посчитали полезным:

crc1 пишет:
Суспендить процесс сразу, результата не дал. Прга запускается
а ты тот процес запускаешь? =)

з.ы. фантастека....

| Сообщение посчитали полезным:

vins пишет:
а ты тот процес запускаешь? =)
Епт, конечно тот, но я в цикле делаю резюме, потом опять суспендю, читаю память и т.д. В памяти OEP патчится, но прога запускается.
Перехват API по методе DillerInc принес результат

| Сообщение посчитали полезным:

а зачем резюм делать до патча? думаешь твой кодес быстрее работает чем прога?
или я чтото не понимаю

| Сообщение посчитали полезным:

crc1 у меня пол года назад такая же фича с гавнопротом была, я тогда тоже GetModuleHandleA перехватил и всё получилось. ХЗ почему в одном случае работает в другом нет Кстати вспомнил один раз даже перехват этой АПИ не помог, по другому как то делал.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

PE_Kill пишет:
Кстати вспомнил один раз даже перехват этой АПИ не помог, по другому как то делал.

Так как код просто эмулился.

PE_Kill пишет:
ХЗ почему в одном случае работает в другом нет

Такое в старе часто встречается.

| Сообщение посчитали полезным:

можно юзать в EBFE где-нить по ходу распаковки в таком месте чтобы на этом EBFE код c OEP
был уже распакован, тогда можно циклически проверять код с OEP(или другого места проги) не боясь что прога запустится,
как только код распаковался можно сделать SuspendThread, убрать EBFE далее по смыслу в зависимости от сложности пакера

| Сообщение посчитали полезным:

__ пишет:
где-нить по ходу распаковки в таком месте чтобы на этом EBFE код c OEP был уже распакован
Ещебы знать где. StarForce v 3.xx.xx не дает себя трассировать

| Сообщение посчитали полезным:

crc1
то место это второй Jmp eax в VM

Циклишь прогу на ОЕП стара, аттачишся, из ОЕП идешь в вызов ВМ смотришь конец функции там есть jmp eax , ставишь на него бряк (один бряк 3 стар позволяет ольке поставить ) , правишь OEP отправляешь прогу на волю как следствие брякаешься смотришь что там в eax , в этом eax идешь в низ функции внимательно высматриваешь первый jmp "кудатотам" , идешь в"кудатотам" там будет начало, таково вида MOV EDX,DWORD PTR DS:[EDI] , в конце этой штуки есть jmp eax за ним куча нулей , там и патч. Адрес второго джампа один и тот же так, что делаешь лоадер, чтоб он туда сразу пачил как надо , через этот джам стар пробежит раз тыщу и раз сто после того как распакует прогу и будет мудрить с импортом, так что там не промахнешся и передачей управления вагон.

| Сообщение посчитали полезным: