И еще раз инжект. Некоторые приложения иногда падают.

PROFi

Честно говоря, с трудом верится. Она бы тогда не справлялась бы и в остальных приложениях. Тем более, если учитывать, что ищу я, собственно, только GetProcAddress, которая всегда по одному и тому же адресу, а все остальные функции получаю через нее.

 

Дошли руки все перепроверить. Внедренный код отрабатывает всегда полностью. Контекст всегда сохраняется и управление передается как раз в то место, откуда оно было прервано. Когда опера падает, падает она похоже чаще всего (если не всегда) у себя в основном потоке в главном модуле, причем при самых разных ситуациях: исполнение в неисполняемой странице, запись в невыделенную страницу и т.п. Попробовал сначала остановить все потоки, потом внедрить код - ничего не дало. Ее точно так же часто выбрасывает (как, впрочем, и не выбрасывает).
В общем есть у кого-нибудь идеи (по обеим частям вопроса)?
z0mailbox
Насчет существования понятия "основной поток". Вы никогда не смотрели заголовок окошка CPU в OllyDbg. Что там написано во время отладки какого-нибудь процесса?

 

l_inc

Тогда хардварный бряк на адрес меняемой иструкции. Возможно идет динамический подсчет CRC модуля. Тогда при чтении измененной инструкции выскочит SoftICE.

- тут все просто, написать любой пример, в первом потоке создать второй и завершить сразу первый. Если приложение тоже завершится, то понятия "основной поток" существует, иначе - это пустословие.

 

PROFi

это эффективно для процессора с несколькими ядрами?

 

l_inc
dll инжектить не проще ?

 

PROFi
Я уже устал повторять. Я уже столько раз сказал, что я не ставлю перехват и не меняю оригинальных инструкций. Еще раз план действий, но более подробно:
I Код на VB (внедряющий код):
1) OpenProcess/VirtualAllocEx/WriteProcessMemory (записывается внедряемый код в выделенную, как PAGE_EXECUTE_READWRITE память)
2) OpenThread (с правами THREAD_SUSPEND_RESUME Or THREAD_GET_CONTEXT Or THREAD_SET_CONTEXT)/SuspendThread/GetThreadContext/WriteProcessMemory (меняю код джампа в соответствии с eip из старого контекста таким образом, чтобы внедренный код после отработки вернулся на место, в котором поток был остановлен)/SetThreadContext (eip устанавливается на память, выделенную в пункте 1.)/ResumeThread/CloseHandle(<хэндл потока>)/CloseHandle(<хэндл процесса>)

II Код на ассемблере (внедряемый код):
1) Инициализируется таблица с адресами необходимых API (в данном случае это только ExitThread и MessageBoxA).
2) Создается новый поток, а управление в этом потоке передается на инструкцию, с которой было приостановлено выполнение оригинального кода Opera.
3) Новый поток выводит MessageBox и завершается.

И на всякий случай еще раз: НИКАКОЙ модификации оригинального кода Opera, НИКАКИХ ПЕРЕХВАТОВ.

 

Asterix
Проще, но чем этот метод не имеет права на существование?
Кроме того, создание удаленного потока очень хорошо палится, лишняя длл-ка в процессе тоже палится. Запись в процесс тоже палится, конечно, но я планирую попробовать не самому открывать процесс, а взять хэндл из csrss.exe. Просто руки пока опять-таки до этого не дошли, но это другая история, которая к вопросу особого отношения не имеет.

 

PROFi

На 98% уверен, что приложение не завершится, но, как я уже писал, при этом основным потоком можно считать либо новосозданный поток, либо считать, что тогда у приложения просто нету основного потока.

 

l_inc

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

 

z0mailbox
ИМХО зря. Юзермодный отладчик тоже нужен в хозяйстве. Да и поудобнее он СофтАйса будет.
Ну ладно. А в MSDN Вы верите? Интересно, сколько раз там встречается словосочетание "primary thread". Вот одна из многочисленных цитат:

 

//

 

Вот глянь код я давно уже писал инжект на masme!

 

l_inc

Во, теперь понял. Попробуй добавь SuspendThread всех потоков в приложении, а не только модифицируемого. Столкнулся с такой фишкой при отладке драйверов nVidea когда перед входом в функцию устанавливается таймер (причем в другом потоке), и если функция отработала не в положенный срок (а это случалось при отладке), то вылетала вообще вся система в BSOD. Возможно здесь имеет место та же ситуация. А вообще желательно работу инжектируемого кода в опере софтайсом проверить

Кроме того, создание удаленного потока очень хорошо палится, лишняя длл-ка в процессе тоже палится. Запись в процесс тоже палится, конечно, но я планирую попробовать не самому открывать процесс, а взять хэндл из csrss.exe. Хендл не есть объект, и потому просто так взять хендл из csrss.exe невозможно (он не будет иметь смысла в текущем контексте процесса), тут драйвер нужон.

что тогда у приложения просто нету основного потока. - это тоже ближе к теме. Существует понятие первичный поток оно ж primary thread по латыне, но понятия основной поток нет.

 

l_inc
примари тред блин - это я врубаюсь, основной - не-а, извиняйте

 

axe_roma
Нулевое впечатление (от предложения посмотреть инжект): "Зачем мне чужой код, если мой - относительно рабочий и проблема явно в приложении, в которое я инжектирую, а не в моем коде?". Ну проблема, конечно, и в коде тоже, но Ваш пример мне много не даст. Как делать инжект в принципе, я в курсе.
Первое впечатление от кода: "Да на такой объем кода полядра WindowsXP влезть может".
Второе впечатление (когда посмотрел список используемых API): "И это инжект?!!! Это пятнадцать троянов, соединенные вместе!". В смысле, элементарный пример инжекта - это считанные строки. А Вы мне такое подсовываете... хоть и с комментариями.
Третье впечатление (когда крутанул скроллбар блокнота в произвольную точку)... это вообще издевательство, а не код! А произвольная точка оказалась вот эта:

Код (Text):

1.         ;Теперь выделяем память для копирования
2.         [b];Ну ладно. Здесь верю.[/b]
3.         invoke VirtualAllocEx,edi,esi,eax,MEM_COMMIT or MEM_RESERVE,PAGE_EXECUTE_READWRITE      
4.         test eax,eax    [b];Проверка тоже вроде не абсолютно лишняя.[/b]
5.         jz ExitIn
6.         [b];А вот это мне в голову не лезет. НАФИГА? Как будто мы сами не знаем, что и с какими правами мы выделили. Это как получить список процессов в одну область памяти, а потом заново создавать снапшот и делать цикл перебора процессов, чтобы в другой области памяти получить то же самое, вместо того, чтобы скопировать то, что уже было получено ранее.
7.         ;Сюда же дальнейшее использование структуры mbi[/b]
8.         invoke VirtualQueryEx,edi,eax,addr mbi,sizeof MEMORY_BASIC_INFORMATION
9.                 xor ebx,ebx    
10.             Fr:        
11.                        [b] ;ИМХО нафига?[/b]
12.                         invoke VirtualProtectEx,edi,esi,1000h,PAGE_EXECUTE_READWRITE,addr dwOldProt
13.                         [b];Ну это вообще ИМХО ни в какие рамки не лезет. Читать из области памяти своего процесса в область памяти чужого, предполагая, что данные в Вашем процессе будут по тому же адресу, что и в чужом.[/b]
14.                          invoke WriteProcessMemory,edi,esi,esi,1000h,addr dwNumBytes
15.                         cmp mbi.Protect,1
16.                         jz ExitIn
17.                         add esi,1000h
18.                         add ebx,1000h
19.                         cmp ebx,mbi.RegionSize
20.                         ;А теперь повторим этот багогенератор.
21.                         jnz Fr

Наверняка я неверно понял, т.к. после этого кусочка кода я больше никуда не смотрел. Испугался.
В принципе все, что я хотел всем вышенаписанным сказать - это то, что подсовывать свой код, когда я прошу найти баг в моем коде - это немного не в тему. Хотя все равно спасибо, т.к. не у всякого не возникает нездоровых мыслей, когда он выкладывает свой код на публику.

 

PROFi

Очень смешной подкол. Как будто я собирался прямо из csrss.exe брать то же числовое значение хэндла, которое там сохранено. А DuplicateHandle на что?
z0mailbox & PROFi

ИМХО Primary thread (хотя часто употребляется в виде main thread) можно перевести, как первичный поток, главный поток, основной поток, и все это будет тем же самым.

 

l_inc

А DuplicateHandle на что - А что она уже OpenProcess не пользует. Тут вот в чем прикол, нужно определится для чего нужен "перехват выполнения" кода. Три ключевые функции палятся любой проактивкой: VirtualAllocEx - (она самая важная) OpenProcess или OpenThread и WriteProcessMemory.
Не палятся обращения к окну, но в Viste уже по другому. Потому если пишется для обычной работы, то нахрена такие извращения, если это по возможности стелс-технология, то полагаться на функции API - бесполезно.
Кстати primary - переводится как первичный, а не как основной.

 

PROFi

Использует. Но во-первых там прав хэндла всего-то и надо, что PROCESS_DUP_HANDLE. Во-вторых открывать-то я буду не тот процесс, в который инжект делаю. Авось и не попалюсь.

Абсолютного стелса придумать ИМХО невозможно. А мне интересно сделать, чтобы седьмой касперский, скажем, на средней эвристике не спалил. Кроме того, я написал, что всего лишь попробую, а не "это будет самый стелсовый стелс и всех стелсов".

Если мне не верите, вот цитата из словаря:

Кроме того, я уже приводил цитату, где используется русский вариант "основной поток". И таких цитат не только в статьях, а в серьезных книжках... я думаю, что смогу полно найти.
Да и собственно это не важно. Не основной, так первичный. Как его ID получить? Или он всегда будет первым, который был возвращен при перечислении потоков?

 

/offtop

однако main thread - определение главного потока процесса, откуда взялось определение Primary thread?

P.S. сами придумали?

 

t00x
Честно говоря, не понял, что Вы хотели сказать. Поэтому:
Первое: "main thread" - не определение, а понятие.
Второе: "главный поток" - перевод словосочетания "primary thread"
Третье:

Я вроде написал, что цитата из MSDN.