Re: Помогите чуток с перехватом API
От: Andrew S Россия http://alchemy-lab.com
Дата: 18.08.03 12:06
Оценка: 1 (1)
В общем, все гораздо печальнее. Можно написАть (и наверняка написана) кучу кода, который использует тот же интерфейс 2Eh для обращения к native api, соответственно, ни один юзер-моде хук не сможет ничего сделать.
Видимо, вам придется писАть фильтр файловой системы под NT и хук файловых операций под 9х. Но это к valerio.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re: Помогите чуток с перехватом API
От: alexandrov_alex США  
Дата: 18.08.03 11:52
Оценка: +1
Здравствуйте, Jungle, Вы писали:

... Пропущено ...

J> 1. Прописываю в ветке реестра HKLM\Software\Microsoft\Windows

J> NT\CurrentVersion\ в параметр AppInit_DLLs путь к своей длл-ке. Все
J> работает пучком. Ни фар, ни ТоталКоммандер, ни Експлорер, ни Волков, ни
J> Ворд (и т.д.) не могут ничего сделать с "неправильным" диском. Но а)
J> все это легко обходится с помощью командной строки б) некоторым прогам
J> (кроме Аутлук Экспресс пока не нашёл) также плевать на мои потуги
J> Лечится только непосредственным внедрением моей длл в процесс Аутлука.
J>
J> Как это побороть?

... Пропущено ...

Увы, уважаемый, должен Вас огорчить. Параметр AppInit_DLLs имеет значение сугубо для библиотеки user32.dll. Именно она его обрабатывает при своей загрузке. Так что если написать программу, не использующую user32.dll, то ваш метод накроется медным тазом. Консольные приложения вообще-то и не используют обычно данную библиотеку, это уж FAR такой умный...

-- Всего хорошего!
-- Alex Alexandrov, e-mail: alexandrov_alex@fromru.com
Posted via RSDN NNTP Server 1.7 beta
It's kind of fun to do the impossible (Walt Disney)
Re[2]: Помогите чуток с перехватом API
От: alexandrov_alex США  
Дата: 19.08.03 06:48
Оценка: +1
Здравствуйте, Блудов Павел, Вы писали:

БП> Здравствуйте, Jungle, Вы писали:

БП>
J>> 2. Вот два отрывка из кода длл. Оба "правильно" работают (т.е. функции
J>> возвращают правильные результаты). Однако в первом варианте при вызове
J>> "родной" АПИ-функции всё работает как было задумано, а во втором
J>> "родные" функции возвращают ошибки.
БП>
БП> Часто это просходит из-за того, что не восстанавливается код ошибки.
БП> У Вас я нигде не встретил на одного вызова ::SetLastError().
БП>
БП> Вы может быть и плевать хотели на этот самый код ошибки, а некотторые
БП> программисты добросовестно вызывают ::GetLastError() при получении
БП> INVALID_HANDLE_VALUE из ::CreateFile(). Возможно, дело в этом.
БП>
БП> Павел.

Да у него ничего не получается, потому что DLL не грузится в адресное пространство клиентов. Я же говорю, параметр AppInit_DLLs обрабатывает только user32.dll, пока ее система не загрузит — фиг, а не перехват функций. И GetProcAddress человек не перехватывает судя по всему. Какая уж тут защита...

-- Всего хорошего!
-- Alex Alexandrov, e-mail: alexandrov_alex@fromru.com
Posted via RSDN NNTP Server 1.7 beta
It's kind of fun to do the impossible (Walt Disney)
Помогите чуток с перехватом API
От: Jungle  
Дата: 18.08.03 11:39
Оценка:
Есть задача. Блокировать все операции с носителем (дискета, зип, флэшка, и т.д.), если он "неправильный". Я написал в VC++ 7 длл, в которой обрабатываю все виды следующих функций:
CreateFile, MoveFile, CreateDirectory, SHCreateDirectory, SHFileOperation, DeleteFile, RemoveDirectory, OpenFile, _lcreat, SetCurrentDirectory, ShellExecute, WinExec, CreateProcess.

1. Прописываю в ветке реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\ в параметр AppInit_DLLs путь к своей длл-ке. Все работает пучком. Ни фар, ни ТоталКоммандер, ни Експлорер, ни Волков, ни Ворд (и т.д.) не могут ничего сделать с "неправильным" диском. Но
а) все это легко обходится с помощью командной строки
б) некоторым прогам (кроме Аутлук Экспресс пока не нашёл) также плевать на мои потуги Лечится только непосредственным внедрением моей длл в процесс Аутлука.

Как это побороть?

2. Вот два отрывка из кода длл. Оба "правильно" работают (т.е. функции возвращают правильные результаты). Однако в первом варианте при вызове "родной" АПИ-функции всё работает как было задумано, а во втором "родные" функции возвращают ошибки. В чём может быть дело (только не надо про ошибку в ДНК, пожалуйста )?

вариант 1.

....
//CreateFileA
BYTE cfa_FirsBytes[JMP_LEN];
BYTE cfa_JmpCmd[JMP_LEN];
DWORD cfa_dwProcAddress = 0;
....

static DWORD GetVolumeSerialA(char *lpPathName)
{
DWORD VolumeSerial = 0;

GetVolumeInformationA(lpPathName, NULL, 0, &VolumeSerial, NULL, NULL, NULL, 0);

return VolumeSerial;
}

//
//Begin OnCreateFileA
//
static HANDLE _stdcall OnCreateFileA(
LPCSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile)
{
DWORD dwProtect;
char drive[4] = {0, 0, 0, 0};
HANDLE hFile = INVALID_HANDLE_VALUE;

VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, PAGE_EXECUTE_READWRITE, &dwProtect);
memmove((LPVOID)cfa_dwProcAddress, cfa_FirsBytes, JMP_LEN);
VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, dwProtect, &dwProtect);

try
{
if (!CheckDBforVolume(GetVolumeSerialA(strncpy((char *)(drive), lpFileName, 3))))
{
hFile = CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes,
dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
}
}
catch (int) {}
/**/

VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, PAGE_EXECUTE_READWRITE, &dwProtect);
memmove((LPVOID)cfa_dwProcAddress, cfa_JmpCmd, JMP_LEN);
VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, dwProtect, &dwProtect);

return hFile;
}
//
//End OnCreateFileA
//

BOOL OnIntercept(HANDLE hModule = NULL)
{
DWORD dwProtect;
DWORD dwTemp;

// Intercept CreateFileA function
cfa_dwProcAddress = (DWORD)GetProcAddress(GetModuleHandle(_T("KERNEL32.DLL")), _T("CreateFileA"));
cfa_JmpCmd[0] = jmp;

dwTemp = ((DWORD)OnCreateFileA) — (cfa_dwProcAddress + JMP_LEN);
memmove(&cfa_JmpCmd[1], &dwTemp, JMP_OPER_LEN);

VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, PAGE_EXECUTE_READWRITE, &dwProtect);
memmove(cfa_FirsBytes, (LPVOID)cfa_dwProcAddress, JMP_LEN);
memmove((LPVOID)cfa_dwProcAddress, cfa_JmpCmd, JMP_LEN);
VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, dwProtect, &dwProtect);

return TRUE;
}


BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved)
{
char szStat[256];

switch (dwReason)
{

case DLL_PROCESS_ATTACH:
return OnIntercept(hModule);

break;

case DLL_PROCESS_DETACH:
break;

case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
break;
}
return TRUE;
}

Вариант 2 (изменены только функции OnCreateFileA и GetVolumeSerialA)

static BOOL GetVolumeSerialA(const LPCSTR lpPathName)
....
{
char Drive[4];
DWORD VSer = 0;

wsprintf(Drive, "%c:\\", char(PathGetDriveNumberA(lpPathName) + 65));

if (!GetVolumeInformation(Drive, NULL, 0, &VSer, NULL, NULL, NULL, 0)) return false;

return CheckDBforVolume(VSer);
}

....

//
//Begin OnCreateFileA
//
static HANDLE _stdcall OnCreateFileA(
LPCSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile)
{
DWORD dwProtect;
DWORD VolSer = 0;
char drive[4] = {0, 0, 0, 0};
HANDLE hFile = INVALID_HANDLE_VALUE;

VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, PAGE_EXECUTE_READWRITE, &dwProtect);
memmove((LPVOID)cfa_dwProcAddress, cfa_FirsBytes, JMP_LEN);
VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, dwProtect, &dwProtect);

if (!GetVolumeSerialA(lpFileName))
{
try
{
hFile = CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes,
dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
}
catch (int) {}
}
/**/

VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, PAGE_EXECUTE_READWRITE, &dwProtect);
memmove((LPVOID)cfa_dwProcAddress, cfa_JmpCmd, JMP_LEN);
VirtualProtect((LPVOID)cfa_dwProcAddress, JMP_LEN, dwProtect, &dwProtect);

return hFile;
}
//
//End OnCreateFileA
//
Re[2]: Помогите чуток с перехватом API
От: Sergey Россия  
Дата: 18.08.03 13:38
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>В общем, все гораздо печальнее. Можно написАть (и наверняка написана) кучу кода, который использует тот же интерфейс 2Eh для обращения к native api, соответственно, ни один юзер-моде хук не сможет ничего сделать.


Вот насчет кучи кода — это вряд ли. IMHO, вся эта куча кода ограничивается системными файлами. Насколько я понимаю, цифровые коды служб интерфейса int 2Eh — просто enum где-то в недрах исходников винды, меняющийся от сборки к сборке, и использовать его в своем коде было бы чистой воды мазохизмом.

AS>Видимо, вам придется писАть фильтр файловой системы под NT и хук файловых операций под 9х. Но это к valerio.


Эт конечно было бы по крайней мере правильней и надежней.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[3]: Помогите чуток с перехватом API
От: Andrew S Россия http://alchemy-lab.com
Дата: 18.08.03 13:49
Оценка:
Ну, от сборки к сборке, насколько я помню, они не меняются. Они просто разные для NT4, NT5 и NT5.1. Если программа конкретно заточена под одну версию системы + есть необходимость не использовать системные библиотеки, даже ntdll.dll — то это один из выходов. В принципе надо учитывать любые исходы, даже такие, на первый взгляд, невероятные.

S>Вот насчет кучи кода — это вряд ли. IMHO, вся эта куча кода ограничивается системными файлами. Насколько я понимаю, цифровые коды служб интерфейса int 2Eh — просто enum где-то в недрах исходников винды, меняющийся от сборки к сборке, и использовать его в своем коде было бы чистой воды мазохизмом.


AS>>Видимо, вам придется писАть фильтр файловой системы под NT и хук файловых операций под 9х. Но это к valerio.


S>Эт конечно было бы по крайней мере правильней и надежней.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[4]: Помогите чуток с перехватом API
От: Sergey Россия  
Дата: 18.08.03 14:38
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>Ну, от сборки к сборке, насколько я помню, они не меняются.


Если не добавлялось новых функций — тогда не меняется. Но, помнится, после SP1 для Win2k какие-то номера функций проехались (впрочем, могу ошибаться).

AS>Они просто разные для NT4, NT5 и NT5.1. Если программа конкретно заточена под одну версию системы + есть необходимость не использовать системные библиотеки, даже ntdll.dll — то это один из выходов.


Очень специфичные требования, не находишь? Вряд ли таких программ (не входящих в дистрибутив виндов) много. Я, по крайней мере, сильно удивлюсь, если мне назовут хоть одну такую коммерческую программу. Другое дело, что можно специально написать программу, обходящую на конкретном компьютере авторизацию доступа к сменному носителю, основанную на перехвате API-функций.

AS>В принципе надо учитывать любые исходы, даже такие, на первый взгляд, невероятные.


Да не, я не спорю, драйвер писать, конечно, правильнее, но на счет кучи кода это ты все-таки загнул.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re: Помогите чуток с перехватом API
От: Блудов Павел Россия  
Дата: 19.08.03 04:23
Оценка:
Здравствуйте, Jungle, Вы писали:

J>б) некоторым прогам (кроме Аутлук Экспресс пока не нашёл) также плевать на мои потуги Лечится только непосредственным внедрением моей длл в процесс Аутлука.


Уточните пожалуйста, Вы перехватываете только
CreateFileA, MoveFileA и т.д. или CreateFileW, MoveFileW и т.д. тоже?
Павел.
Re: Помогите чуток с перехватом API
От: Блудов Павел Россия  
Дата: 19.08.03 04:27
Оценка:
Здравствуйте, Jungle, Вы писали:

J>2. Вот два отрывка из кода длл. Оба "правильно" работают (т.е. функции возвращают правильные результаты). Однако в первом варианте при вызове "родной" АПИ-функции всё работает как было задумано, а во втором "родные" функции возвращают ошибки.


Часто это просходит из-за того, что не восстанавливается код ошибки.
У Вас я нигде не встретил на одного вызова ::SetLastError().

Вы может быть и плевать хотели на этот самый код ошибки, а некотторые
программисты добросовестно вызывают ::GetLastError() при получении
INVALID_HANDLE_VALUE из ::CreateFile(). Возможно, дело в этом.

Павел.
Re[2]: Помогите чуток с перехватом API
От: Valerio Россия linkedin.com/in/boronin
Дата: 19.08.03 05:30
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>В общем, все гораздо печальнее. Можно написАть (и наверняка написана) кучу кода, который использует тот же интерфейс 2Eh для обращения к native api, соответственно, ни один юзер-моде хук не сможет ничего сделать.

абсолютно верно

просто пример: сейчас существуют очень большие продукты корпоративного клиент-серверного уровня которые целиком живут в kernel и соотв. используют либо Zwxxx либо roll your own IRP метод для работы с файлами: все эти продукты не совместимы с Вашим подходом by design.

AS>Видимо, вам придется писАть фильтр файловой системы под NT и хук файловых операций под 9х. Но это к valerio.

да, только так

J>Есть задача. Блокировать все операции с носителем (дискета, зип, флэшка, и т.д.), если он "неправильный". Я написал в VC++ 7 длл, в которой обрабатываю все виды следующих функций:

J>CreateFile, MoveFile, CreateDirectory, SHCreateDirectory, SHFileOperation, DeleteFile, RemoveDirectory, OpenFile, _lcreat, SetCurrentDirectory, ShellExecute, WinExec, CreateProcess.
а Вы ведь даже не протестили на всех ОС и их разновидностях индокитайских включая все SP и уже получили проблемы с не 100% перехватом (значит просто неработающим )

где гарантия что Вы весь набор Win32 API существующего и будущего перечислили? в 2003 например есть новые ф-ии вроде ReOpenFile

самый правильный вариант это фильтр файловой системы и все пойдет через Вас — вот здесь будет гарантия что все честно и будет работать всегда и везде и даже может вполне быть binary compatible from NT4.0 till 2k3, i.e. only one .sys file for all NT versions (File System interface is one of most stable API from MS — very good design IMHO)
... << RSDN@Home 1.1 beta 1 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.