Вылетает на CreateRemoteThread >:-[]

Всем Доброго Времени Суток!! Пишу программу которая должна запустить некоторый ехе-код внутри другого процесса, но проблема в том что программа просто вылетает на CreateRemoteThread. Да ещё проблема в том, что я понятия не имею как должен быть устроен код, внедряемый в процесс.
Сам запускающий код выглядит следующим образом:

Code (Text):

1. format pe gui 4.0
2. include 'win32ax.inc'
3.  
4. .data
5. p_info  PROCESS_INFORMATION
6. s_info  STARTUPINFO
7. hFile   rd 1
8. _out    rb 30
9. NumOfB  rb 100
10. mem     rd 1
11. size    rd 1
12. buff    rb 1536
13.  
14. .code
15. start:
16. mov [s_info.cb],sizeof.STARTUPINFO
17. mov [s_info.hStdError],0
18. mov [s_info.hStdOutput],0
19. mov [s_info.hStdInput],0
20. mov [s_info.dwFlags],100h                 ; STARTF_USESTDHANDLES
21.  
22. invoke CreateProcess,"C:\Windows\notepad.exe",NULL,NULL,NULL,FALSE,NORMAL_PRIORITY_CLASS,NULL,NULL, s_info, p_info
23. invoke CreateFile,"InjectProg.EXE",GENERIC_READ,FILE_SHARE_WRITE+FILE_SHARE_READ,0,\
24. OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0
25. cmp    eax,-1
26. je     _err
27. mov    [hFile],eax
28. invoke GetFileSize,[hFile],NULL
29. mov    [size],eax
30. invoke wsprintfA,_out,"Размер файла %d",[size]
31. invoke VirtualAllocEx,[p_info.hProcess],0,[size],MEM_COMMIT,PAGE_EXECUTE_READWRITE
32. mov    [mem],eax
33. ;invoke wsprintfA,_out,"Освобождено по адр. %d",[mem]
34. ;invoke MessageBox,0,_out,"ProgDLL0.DLL",0
35. invoke ReadFile,[hFile],buff,[size],NumOfB,0
36. cmp eax,0
37. je _err
38. invoke CloseHandle,[hFile]
39. invoke WriteProcessMemory,[p_info.hProcess],[mem],buff,1536,0
40. ;invoke CreateRemoteThread,[p_info.hProcess],0,0,[mem],0,0,0
41. ;invoke CloseHandle,eax
42. exit:
43. invoke ExitProcess,0
44. _err:
45. invoke  MessageBox,HWND_DESKTOP,"error",invoke GetCommandLine,MB_ICONERROR
46. jmp exit
47. .end start

А так выглядит вводимый код, на счет которого у меня большие сомнения:

Code (Text):

1. format PE GUI 4.0
2. include 'win32a.inc'
3.  
4. section '.code' code readable executable
5.  
6.  
7. proc Inj
8. invoke MessageBox,0,"stop","stop",MB_OK
9. ;--------помещаем текст--------------------------
10. invoke MessageBox,HWND_DESKTOP," После нажатия ОК откроется шрифт по настройкам меню",0,MB_OK
11. invoke FindWindowExA,<invoke FindWindow,'notepad',0>,0,'edit',0
12. mov    [hw],eax
13. invoke SendMessageA,[hw],WM_SETTEXT,0,msg
14. ;--------первый вариант шрифта---------------------
15. invoke MessageBox,HWND_DESKTOP,"После нажатия ОК откроется изменённый шрифт(первый вариант)",0,MB_OK
16. invoke CreateFontIndirectA,lf1
17. invoke SendMessageA,[hw],WM_SETFONT,eax,TRUE
18. invoke DeleteObject,lf1
19.  
20.  
21. ;-------второй вариант шрифта-----------------------------
22. invoke MessageBox,HWND_DESKTOP,"После нажатия ОК откроется изменённый шрифт(второй вариант)",0,MB_OK
23. invoke CreateFontIndirectA,lf2
24. invoke SendMessageA,[hw],WM_SETFONT,eax,TRUE
25. invoke DeleteObject,lf2
26. ret
27. endp
28.  
29.  
30. section '.data' data readable writeable
31. lf1 LOGFONT \
32. 12,7,\ ;lfHeight & lfWidth
33. 0,0,\ ;lfEscapement(наклон отн. Х в 10х градуса) & lfOrientation
34. FW_NORMAL,0,0,0,\ ;lfWeight & lfItalic & lfUnderline & lfStrikeOut
35. RUSSIAN_CHARSET,\ ;lfCharSet
36. OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY,\ ;lfOutPrecision & lfClipPrecision & lfQuality
37. FF_MODERN+FIXED_PITCH,\ ;lpPitchAndFamily ;FIXED_PITCH=моноширинный=красивосорцен Ж)
38. <"Tw Cen MT",0> ;lfFaceName
39.  
40. lf2 LOGFONT \
41. 12,7,\ ;lfHeight & lfWidth
42. 0,0,\ ;lfEscapement(наклон отн. Х в 10х градуса) & lfOrientation
43. FW_NORMAL,0,TRUE,0,\ ;lfWeight & lfItalic & lfUnderline & lfStrikeOut
44. RUSSIAN_CHARSET,\ ;lfCharSet
45. OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY,\ ;lfOutPrecision & lfClipPrecision & lfQuality
46. FF_MODERN+FIXED_PITCH,\ ;lpPitchAndFamily ;FIXED_PITCH=моноширинный=красивосорцен Ж)
47. <"courier new",0>
48.  
49. msg db 'fedcb9870',0
50. hw rd 1
51.  
52. section '.idata' import data readable writeable
53.  
54.   library kernel,'KERNEL32.DLL',\
55.           user,'USER32.DLL',\
56.           shell,'SHELL32.DLL',\
57.           gdi,'GDI32.DLL'
58.  
59.   import user,\
60.          MessageBox,'MessageBoxA',\
61.          FindWindowExA,'FindWindowExA',\
62.          FindWindow,'FindWindowA',\
63.          SendMessageA,'SendMessageA'
64.  
65.   import gdi,\
66.          CreateFontIndirectA,'CreateFontIndirectA',\
67.          DeleteObject,'DeleteObject'

 

Вы скопипастили код, и хотите понять почему не работает?

 

'invoke WriteProcessMemory,[p_info.hProcess],[mem],buff,1536,0' завершается корректно?

P.S. Для внедрения библиотеки в адресное пространство процесса лучше создавать удаленный поток с точкой входа в LoadLibrary и параметром-путем к загружаемой библиотеке. Тогда загрузчик сам разрешит все зависимости библиотеки.

 

Да, завершается нормально.

Написал руками и ищу ошибку. И где я писал про копипасту?

 

Внедряемый код должен быть базонезависимым.

 

А что требуется для базонезависимости?

 

Во-первых, оно криво компилится в fasm. Во-вторых, если вы делаете базонезависимый код, то вся адресация должна быть относительно начала кода. Начало кода вычисляется через дельта смещение (call $ + 5 / pop reg). Адреса апи должны вычисляться динамически (обычно через peb находят адрес загрузки kernel32.dll и пляшут от него). Фактически у вас сейчас три секции, а должна быть одна.

 

Flint_ta
Способ, который я описал, не требует базонезависимости, можно загружать динамическую библиотеку, главное, чтобы в ней были релокации.

 

не должен если внедряеш dll

 

Ну, видимо, написать длл с релоками и пройтись по ним один раз во временном буффере до записи через WriteProcessMemory -
это что-то из области фантастики )
Вообще, релокнуть образ для перемещения совершенно ничего экстраординарного не представляет.

Завершаться она может и нормально, но ничего не писать. Сколько конкретно она возвращает dwBytesWritten - столько же, сколько было передано?

 

о_0 а как же пишете тогда?
Короче, основной момент: нужно переносить образ длл целиком (не обязательно, но так удобнее; да и не будут спрашивать тогда "а почему данные и импорт не работают?") во-первых, нужно применить релоки для адреса назначения во-вторых.
иначе в другой процесс уйдет код, который настроен для работы по одному базовому адресу, а запущенный по другому базовому адресу.

Во-вторых,

1536 - это размер ВСЕГО модуля?
Если да - ты потом передаешь управление куда, на ImageBase? Опять же, тогда управление надо передавать не на начало, а на точку входа.
Не, чувак, так не пойдет - грузить с диска файл и сразу его отправлять. Нужно выполнить _вручную_ всю работу Windows загрузчика. Будет проще, если переносить уже загруженный модуль, например, текущий. Размести код для переноса и переносящий код в одной длл и переноси ее уже из памяти в память, тогда останется только применить релоки.

А вообще, как уже сказали, будет гораздо проще вызвать в процессе назначения LoadLibrary с именем длл, чем сейчас объяснять все тонкости. И всю работу тогда выполнит системный загрузчик, потому что в ином случае придется ручками все фиксить.

PS. Как пример кода для применения релокаций: http://www.rsdn.ru/forum/src/3202881.flat.aspx
Тебе нужны LdrProcessRelocationBlock и LdrProcessRelocations. Пример вызова:

Code (Text):

1. PVOID ImageBase = VirtualAlloc (...); // make temporary buffer
2. memcpy (ImageBase, GetModuleHandle(..), ..); // make copy of the image to be transferred
3.  
4. PIMAGE_DOS_HEADER DosHeader = (PIMAGE_DOS_HEADER) ImageBase;
5. PIMAGE_NT_HEADERS NtHeaders = (PIMAGE_NT_HEADERS) ((PUCHAR)ImageBase + DosHeader->e_lfanew);
6. PIMAGE_BASE_RELOCATION BaseRelocs = (PIMAGE_BASE_RELOCATION) ((PUCHAR)ImageBase + NtHeaders->OptionalHeader.DataDirectory [IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress);
7. LONG_PTR lImageBaseDelta = (LONG_PTR)mem - (LONG_PTR)ImageBase; // image base delta
8.  
9. LdrProcessRelocations (ImageBase, lImageBaseDelta, NtHeaders, BaseRelocs);

PS2. Ну а про базонезависимый код и ручной поиск апи - смешно, смешно) Если нифига не знаете, зачем отвечать?

 

При чем тут dll и релоки? У ТС в примере exe и без релоков.

 

Flint_ta
Ну да, конечно.

Code (Text):

1. ;invoke MessageBox,0,_out,"ProgDLL0.DLL",0

У него длл читается из файла. Иди спать дальше ) Ручной поиск, блин
Да и даже если был бы exe, все равно я описал как _нужно_ делать. Писать в ехе тучу говнокода, чтобы потом перенести весь этот говнокод по парсингу импорта через peb в другой процесс - так точно делать не нужно. (ТС не знает даже как код переносить, о каком peb вообще идет речь?)

 

А к чему такие сложности -- руками проходиться по релокациям и т.д? Гораздно проще выделить в адресном пространстве целевого процесса кусочек памяти, записать туда путь к библиотеке и вызвать CreateRemoteThread, передав в него адрес LoadLibrary как start routine и адрес выделенной памяти с путем к библиотеке? Получится, что мы вызываем LoadLibrary(pathname) в целевом процессе. Тогда загрузчик все сделает сам, а нам лишь останется получить управление в DllMain.

 

Mika0x65
Да, как я уже сказал, если лень это все делать, то

Меня никто не читает, да?) К тому же, разве это сложности? Сложности - это как выше предлагали вручную искать апи через peb А корректная обработка релоков - это сотня-полторы строчек, не больше.

Просто этот способ не пойдет, если нет отдельной длл. Например, запускается ехе и копирует свое тело в чужое ап.
Тогда никакими лоад либрари ты не подгрузишь его в чужое АП, и чтобы корректно обработались импорты (через LoadLibraryEx можно подгрузить ехе, но на то он и DONT_RESOLVE_DLL_REFERENCES - референсы (импорты) не будут обработаны).
Тогда единственный вариант - собрать ехе с релоками и вручную переносить.

 

Great
Я еще во втором сообщении это написал, хотя и не очень подробно, так что это меня никто не читает . Другое дело, что я не смотрел как дела обстоят с ASLR. Кажется, там библиотеки грузятся по одному и тому же адресу во всех процессах и адрес меняется каждый раз после перезагрузки, но точно не уверен.

 

Mika0x65
Да нет, я тебя прочитал и ответил тебе еще в первом своем посте) И написал, в каких случаях твой метод подходит, а в каких нет)

Да, верно.
Но я тебе уже написал, почему твой метод не годится: для этого нужно иметь на диске отдельную длл. Что является большим и безоговорочным минусом.
Хотя, безусловно, для ТС это будет куда проще, чем вручную парсить релоки, я согласен. Тут уже ему выбирать в зависимости от его задач.

 

вот на,данный код запустит мессадж в explorer.exe.
только твоему аверу это врятли понравится.

Code (Text):

1. format PE GUI 4.0
2. entry start
3.  
4. include 'win32a.inc'
5.  
6.  
7. struc PROCESSENTRY32
8. {
9.     .dwSize dd ?
10.     .cntUsage dd ?
11.     .th32ProcessID dd ?
12.     .th32DefaultHeapID dd ?
13.     .th32ModuleID dd ?
14.     .cntThreads dd ?
15.     .th32ParentProcessID dd ?
16.     .pcPriClassBase dd ?
17.     .dwFlags dd ?
18.     .szExeFile db 260 dup(?)
19. }
20.  
21. struc _LUID_AND_ATTRIBUTES
22. {
23.     .Luid dq ?
24.     .Attributes dd ?
25. }
26.  
27. struc _TOKEN_PRIVILEGES
28. {
29.     .PrivilegeCount dd ?
30.     .Privileges _LUID_AND_ATTRIBUTES
31. }
32.  
33. TH32CS_SNAPPROCESS  = $00000002;
34. TOKEN_QUERY = $0008;
35. TOKEN_ADJUST_PRIVILEGES = $0020;
36.  
37. SE_PRIVILEGE_ENABLED= $00000002;
38.  
39. section '.code' code executable readable writeable
40.  
41. RemoteCodeStart:
42.     call .delta
43.    .delta:
44.     pop ebp
45.     sub ebp, .delta
46.  
47. ;-------------------------------------------------------
48.  
49.     www1:
50.     push 0
51.     lea eax, [ebp+szCapt]
52.     push eax
53.     lea eax, [ebp+www]
54.     push eax
55.     push 0
56.     call  [ebp+pMessageBoxA]
57.  
58.    .thrend:
59.     push 0
60.     call [ebp+pExitThread]
61.  
62. ;----------------------------------------------------------------------------------
63.  
64. szCapt   db 'Hacker',0
65. www      db 'Hello Hacker',0
66.  
67.  
68.  
69.  
70. pMessageBoxA        dd 0
71. pExitThread         dd 0
72.  
73.  
74. RemoteCodeEnd:
75. RemoteCodeSize equ RemoteCodeEnd-RemoteCodeStart
76.  
77. section '.code' code executable readable writeable
78. TokenPrivs _TOKEN_PRIVILEGES
79. SeDeugPriv db 'SeDebugPrivilege',0
80. winlogon_procname db 'explorer.exe',0
81. proc_entry PROCESSENTRY32
82. pe_size:
83. PROCESSENTRY32_structsize equ pe_size-proc_entry
84.  
85. ProcessSnapshotHandle dd 0
86. WinlogonProcHandle dd 0
87. RemoteThreadBaseAddress dd 0
88. RemoteThreadID dd 0
89. TokenHandle dd 0
90.  
91. Writed dd 0
92.  
93. start:
94.     invoke GetCurrentProcess
95.     invoke OpenProcessToken, eax, TOKEN_ADJUST_PRIVILEGES or TOKEN_QUERY, TokenHandle
96.     invoke LookupPrivilegeValue, 0, SeDeugPriv,  TokenPrivs.Privileges.Luid
97.     mov [TokenPrivs.PrivilegeCount], 1
98.     mov [TokenPrivs.Privileges.Attributes], SE_PRIVILEGE_ENABLED;
99.     invoke AdjustTokenPrivileges, [TokenHandle], FALSE, TokenPrivs, 0, 0, 0
100.  
101.     test eax, eax
102.     jnz @f
103.     jmp .exit
104.    @@:
105.     ;debug privilege is enabled
106.     invoke CreateToolhelp32Snapshot, TH32CS_SNAPPROCESS, 0
107.     mov [ProcessSnapshotHandle], eax
108.  
109.     mov [proc_entry.dwSize], PROCESSENTRY32_structsize
110.  
111.     invoke Process32First, eax, proc_entry
112.    .rep:
113.     invoke lstrcmpi, winlogon_procname, proc_entry.szExeFile
114.     cmp eax, 0
115.     jz .endrep
116.     invoke Process32Next, [ProcessSnapshotHandle], proc_entry
117.     jmp .rep
118.    .endrep:
119.  
120.     invoke OpenProcess, PROCESS_CREATE_THREAD or PROCESS_VM_OPERATION or PROCESS_VM_WRITE, FALSE, [proc_entry.th32ProcessID]
121.     mov [WinlogonProcHandle], eax
122.  
123.     test eax, eax
124.     jnz @f
125.     jmp .exit
126.    @@:
127.  
128.     mov eax, [MessageBoxA]
129.     mov [pMessageBoxA], eax
130.     mov eax, [ExitThread]
131.     mov [pExitThread], eax
132.  
133.  
134.     invoke VirtualAllocEx, [WinlogonProcHandle], 0, RemoteCodeSize, MEM_COMMIT+MEM_RESERVE, PAGE_EXECUTE_READWRITE
135.     mov [RemoteThreadBaseAddress], eax
136.     invoke WriteProcessMemory, [WinlogonProcHandle], eax, RemoteCodeStart, RemoteCodeSize, Writed
137.     invoke CreateRemoteThread, [WinlogonProcHandle], 0, 0, [RemoteThreadBaseAddress], 0, 0, RemoteThreadID
138.  
139.    .exit:
140.     invoke ExitProcess, 0
141.  
142.  
143.   section '.idata' import data readable writeable
144.  library kernel32,'KERNEL32.DLL',\
145.           user32,'USER32.DLL',\
146.           gdi32,'GDI32.DLL',\
147.           advapi32,'ADVAPI32.DLL',\
148.           comctl32,'COMCTL32.DLL',\
149.           comdlg32,'COMDLG32.DLL',\
150.           shell32,'SHELL32.DLL',\
151.           wsock32,'WSOCK32.DLL'
152.  
153.   include 'api/kernel32.inc'
154.   include 'api/user32.inc'
155.   include 'api/gdi32.inc'
156.   include 'api/advapi32.inc'
157.   include 'api/comctl32.inc'
158.   include 'api/comdlg32.inc'
159.   include 'api/shell32.inc'
160.   include 'api/wsock32.inc'

 

Всем привет!
У меня похожая ситуация, и не много не понятная.

1. Отдельно от всего отладил код который будет инжектитьса, работает без збоев.
2. Програма-носитель успешно инжектит код (ну например в експлорер.ехе) и вызывает CreateRemoteThread() после чего завершаетса.

Удаленный поток получив управление рушит експлорер наповал. (старнно, потому-что пикод отлажен и работает).

Короче открываю Ольку, ставлю бряк на создание нового потока аттачусь к експлореру и вот тут-то начинается самое интересное.
В внедренный поток я то попадаю, толко отлаживать уже нихера не могу, в статусе Ольки уже стоит access violation.
ни с F8 ни с F7 ни с F9 я продвинутьса ни на шаг уже не могу.
Вопрос: Что это за явление???
Тестировал на win 7 32bit и на win xp sp3, везде одно и тоже...

Подведем итоги:
1. инжектируемый код работает (100%).
2. код инжектится корректно.
3. CreateRemoteThread() завершаетса успешно.
4. Поток получив управление в експлорере рушит его.
5. Отлаживать внедренный поток не удаетса.

Ваши идеи господа???

 

файл вылаживайте, скорее всего поток начинает исполняться не оттуда где запланировано, т е адрес расчитываете неверно