Просмотр выполняемого кода по адресу возращенному с NtMapViewOfSection

Добрый день.
Вот есть код : http://rootkit.com/newsread.php?newsid=715
NtMapViewOfSection возвращает адрес 00150000 , но ни в WinDbg ни в Олли не могу увидеть этой секции и , естественно, проследить какой код выполняется после вызова QueueUserAPC. То есть грубо говоря, не могу поставить туда бряк и вообще отобразить этот участок. Скажите, как поступают в таких случаях и каким способом можно проследить выполнение шелкода.
Благодарю за внимание.

 

Можно сделать первым байтом шелкода int3. Выглядит странно хотя.

 

Статья ниочём. В оле карту памяти посмотрите, там проекция будет, её не может не быть. А апк - так это ядерный калбэк, его адрес фиксирован - ntdll!KiUserApcDispatcher(), а указатель на пользовательский обработчик передаётся параметром, туда и следует ставить останов.

 

Быть, может не в том процессе смотрите?

+1 :\
постят хрень какую-то. как будто никто никогда не слышал про ZwMapViewOfSection

 

В том то и дело что нет такой секции в Ольке. Вот идет 00140000, далее 00160000 или 00170000. При попытке явного указания адреса в окне дампа, пишет что такого адреса не существует. Для прикола возьмите компильните сорец и сами увидите что нет.
пс. Почему хрень постят?Просто нет никаких коментов, просто код. А кода в сети не так уж много , все CreateRemoteThread или SetThreadContext, из пустого в порожнее. Правда то что метод палиться уже может - это другой вопрос, паблик быстро расхватывают )

 

При чем тут комменты?
Просто статья написана так, как будто это супер-пупер что-то новое, хотя это страшный боян.
Обычный инжект легальными методами. Ничуть не лучше, чем WriteProcessMemory

А маппинг должен быть. Либо ты не в том контексте смотришь, либо не знаю, руки кривые)

 

Маловероятно, что это уже детектируется. Всего два года с небольшим прошло с момента публикации статьи – индустрия защиты не настолько серьёзный бизнес, чтобы так быстро схватывать новые техники.
Теперь, paymera, однозначный, конкретный вопрос: какой процесс открываешь дебаггером?

 

Sol_Ksacap

Я уже как почти 2 года юзаю это чтуку для обмена между процессами, и статья явно не первый источник. Да и дырки эти уже закрыты, по крайней мере на мою "легальную" программу ругается кашпер

 

По-моему, автор так и не ответит на вопрос, из какого все-таки процесса он смотрит виртуальную память..

 

Sol_Ksacap
Для NtMapViewOfSection понадобиться хендл процесса, когда ты полезешь его получать заругается любая нормальная проактивка. Так что такие методы давно детектируются.

 

А насчет первого источника - первым заюзал это эмси рем.

 

TSS
Ну так сою секцию мапить не нужно, есть уже готовые - Cicero и Shim к примеру, которые мапяться ко всем GUI-процессам и можно свободно открывать для записи.

 

Ну я про технику описанную в статье говорил.

 

В статье все движения выполняет родительский процесс, там и техники нет - создали процесс, замапили файл и апк доставили.

 

Я и не спорил что статья шлак =) Кстати ко всем GUI процессам мапиться только Shim, а Cicero замаплена только в эксплорер ( по крайней мере у меня так ). Да и для инжекта в csrss например это не подходит.

 

Сейчас глянул, comodo 3.0 хватает NtOpenSection, так что вобщем открытие секции тоже палится. Хлам вобщем эти секции.

 

SPA
TSS
Вы, ребята, великолепно уловили суть нашего поста. Нам ничего не остаётся, кроме как передать вам заслуженный приз. Пользуйтесь на здоровье!

 

TSS
Хватает сервис - это есчо ниочём не говорит. Имя важно и директория, например когдато киса отслеживала физиклмемори, но не следила за хэндлом директории, так что свободно она открывалась, нлс или модуля например открываются и никто не орет при этом. Это системный механизм, обьект и говорить что хлам просто глупо.

 

Clerk
Ну да, это я поспешил с выводами конечно.
Sol_Ksacap
:P

 

Код (Text):

1. __extern dllexport ULONG __stdcall RemoteCallSystem(
2.     __in HANDLE Process,
3.     __in const wchar_t * Library,
4.     __in const char * Function,
5.     __in_opt const PVOID * Params,
6.     __in int paramcount
7.     )
8. {
9.     int i,codesize;
10.     BYTE *code, *codeaddr, *codebase;
11.     SIZE_T cb;
12.     ULONG RelAddr,result,StackReserved,StackCommit;
13.     CLIENT_ID cid;
14.     HMODULE lib,kernel32;
15.     HANDLE hthread;
16.     kernel32 = GetModuleHandleW(TEXT("kernel32.dll"));
17.     if (kernel32==NULL)
18.         return 0;
19.     //Build Code
20.     //=================================================
21.     codesize = paramcount*5+17;//13+4(result)
22.     //eval function relative address
23.     codebase = (BYTE *)VirtualAllocEx(Process,NULL,codesize,MEM_COMMIT | MEM_RESERVE,PAGE_EXECUTE_READWRITE);
24.     if (codebase == NULL)
25.         return 0;
26.     lib = GetModuleHandleW(Library);
27.     if (lib == NULL)
28.     {
29.         VirtualFreeEx(Process,codebase,0,MEM_RELEASE);
30.         return 0;
31.     }
32.     RelAddr = (ULONG)GetProcAddress(lib,Function);
33.     RelAddr -= ((ULONG)codebase+(paramcount+1)*5);
34.     codeaddr = (BYTE *)ReVirtualAlloc(NULL,0,codesize,PAGE_READWRITE);
35.     code = codeaddr;
36.     //build params
37.     for (i=0;i<paramcount;i++)
38.     {
39.         code[0] = 0x68;//push dword
40.         code += 1;
41.         memcpy(code,&Params[i],4);
42.         code += 4;
43.     }
44.     //build call function
45.     code[0] = 0xE8;//call near relative address
46.     code += 1;
47.     memcpy(code,&RelAddr,4);
48.     code += 4;
49.     //build store eax(result) in memory
50.     code[0] = 0xA3;//mov [mem],eax
51.     code += 1;
52.     result = (ULONG)codebase+codesize - 4;
53.     memcpy(code,&result,4);
54.     code += 4;
55.     code[0] = 0xC2;//retn 0xC0
56.     code[1] = 0x0C;
57.     code[2] = 0x00;
58.     //write builded code
59.     WriteProcessMemory(Process,codebase,codeaddr,codesize,&cb);
60.     //free code
61.     VirtualFree(codeaddr,0,MEM_RELEASE);
62.     //=============================================
63.     //Create Thread
64.     StackReserved = 10240;
65.     StackCommit = 10240;
66.     if (!NT_SUCCESS(RtlCreateUserThread(Process,NULL,TRUE,0,&StackReserved,&StackCommit,GetProcAddress(kernel32,"ExitThread"),NULL,&hthread,&cid)))
67.     {
68.         VirtualFreeEx(Process,codebase,0,MEM_RELEASE);
69.         return 0;
70.     }
71.     //Queue Asyncronous Procedure Call in created thread
72.     ZwQueueApcThread(hthread,(PIO_APC_ROUTINE)codebase,NULL,NULL,0);
73.     //start thread (calling APC)
74.     ResumeThread(hthread);
75.     //waiting to thread finish
76.     WaitForSingleObject(hthread,INFINITE);
77.     //reading result
78.     ReadProcessMemory(Process,(LPCVOID)result,&result,4,&cb);
79.     VirtualFreeEx(Process,codebase,0,MEM_RELEASE);
80.     CloseHandle(hthread);
81.     return result;
82. }
83.  
84. ULONG __stdcall InjectSelfToProcessExRT(
85.     __in HANDLE Process
86.     )
87. {
88.     void * NameBufPtr;
89.     ULONG result;
90.     PVOID * Params;
91.     size_t len;
92.     len = wcslen(ModulePath);
93.     NameBufPtr = VirtualAllocEx(Process,NULL,len*2+2,MEM_COMMIT | MEM_RESERVE,PAGE_READWRITE);
94.     if (NameBufPtr == NULL)
95.         return 0;
96.     WriteProcessMemory(Process,NameBufPtr,ModulePath,len*2+2,NULL);
97.     Params = (PVOID *)calloc(1,4);
98.     if (Params == NULL)
99.     {
100.         VirtualFreeEx(Process,NameBufPtr,0,MEM_RELEASE);
101.         return 0;
102.     }
103.     Params[0] = NameBufPtr;
104.     result = RemoteCallSystem(Process,TEXT("kernel32.dll"),"LoadLibraryW",Params,1);
105.     free(Params);
106.     VirtualFreeEx(Process,NameBufPtr,0,MEM_RELEASE);
107.     return result;
108. }