Впервые такое вижу. В общем есть приложение, которое в несколько потоков дерет один файл, причем всяко разно (гуляет по оффсетам, собирает инфу, преобразует, гуляет +).

Короче нужна помощь - Filemon не справляется с задачей явно, многие моменты чтения явно упускает (под явно имеется в виду, что инфа в ехе не зашите, 100% есть в файле, но чтение ее не происходит (т.е. она не попадает ни в один прочтенный блок). В фильтр стоит лишь имя файла, поэтому все равно должно быть сколько потоков и как что делают. То ли дело в каком то внутреннем таймауте филимона, то ли у мну крыша едит.

Как сделан филимон? Хук на функции работы с файлами? или иным макаром? Вот думаю может имеет смысл чиркануть небольщую утиль, которая бы хучила CreateFile, ReadFile? Или же все-таки дело не в филимоне?

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

я как ламер могу сказать своё мнение.
FileMon наверное направлен больше на общую картину, нежели на точное измерение каждого байта. возможно, если он действительно "пропускает" потоки, то интервалы его проверок выше чем интервалы приложения, которое дерёт этот файл...
ну ещё можно попробовать изменить настройки FileMon. например, вдруг вы по чистой случайности не заметили пункт меню Avanced Output. или какой-то глюк, например у меня одна из предпоследних версий FileMon и RegMon иногда отказывалась фильтровать проессы и выводила сразу все. всякое может быть, даже учитывая то что это одна из самых распростанённых программ такого плана.

сорри если туплю, я уже сказал что я ламер.

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

NaumLeNet пишет:
То ли дело в каком то внутреннем таймауте филимона, то ли у мну крыша едит.
Работа с файлами гораздо больше времени занимает,чем работа с памятью. У филимона есть только вывод протокола - поэтому он должен успевать и никаких таймаутов у него нет, скорее всего.
Проверь, может отключил перехват каких-то дисков - я тут для экономии отключил один раз и потом долго удивлялся.

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

tundra37
фишка в том, что чтение файла я вижу, но оно явно не полное. т.е. филимон контролит обращение к этому файлу, но не до конца. либо у меня паранойя и надо пересматривать все что накопал до этого +))

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

Насколько я помню, филимон не ловит обращения к Memory Mapped файлам. Т.е. само открытие и закрытие он ловит, а вот все что происходит с ним в то время, когда он спроецирован в память пропускает.

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

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

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

С тем как филимон работает разобрался. в итоге плюнул на него и сделал все на уровне хуков. Прохучил CreateFileA/W, ReadFile, CreateFileMapping, SetFilePointer - получил потрясную картину ) Все просто как надо.

Только вот вопрос один к отцам появился. Открытие файла ловлю спокойно, закрытие файла происходит через CloseHandle(hObject: THandle); stdcall; (kernel32.dll, понятное дело). Но сами понимаете, что вызовов CloseHandle своим хуком ловлю туеву хучу на протяжении работы программы. Как бы еще в момент хука определить что за хэндл пытаются закрыть? Уже у себя в программе, вне хук-либы, я могу сравнить его с хэндлом открытого файла и фильтрануть, а вот в хук-либе как быть =( Нету ли какого-нить API для определения принадлежности?

edited
если хреново выразился и не ясно - то я говорю о том что CloseHandle'ов туева хуча в самых разных моментах работы, там даже когда Pen / Brush или еще что-либо создается и то CloseHandle в итоге вызывается )

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

MiraclE пишет:
тогда из за переполнения буфера
Но тогда информация пропадала бы случайно. Тогда надо смотреть/задавать время запроса, чтобы оценить загрузку. Да и переполнить буфер могут только асинхронные запросы - это тоже можно проследить. Обмен с ожиданием будет сам себя тормозить.

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

NaumLeNet пишет:
CloseHandle'ов туева хуча в самых разных моментах работы
Из чисто теоритических соображений (допускаю, что несу полный бред):
в stdio растет функция FILE * _fdopen(int handle,char * mode), наверное можно попробовать после захучивания CloseHandle сокрмить handle этой функции (если после хука можно выполнить левую функцию в контексте процесса) и что-то я сомневаюсь, чтобы Brush какой-нить в структуру не NULL возвратит.

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

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

тут есть специалисты по хукам? еще пара вопросов висит в воздухе. чтобы не заграмождать крякерский форум подобной чепухой - в личку, если есть возможность проконсултировать.

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

NaumLeNet пишет:
Нету ли какого-нить API для определения принадлежности?
OllyDebug в своем окошке Handles как-то это определяет. Покопался в нем, в соответствующем месте обнаружил использование функций ZwQuerySystemInformation, ZwDuplicateObject и ZwQueryObject. С ними попробуй поразбираться.

NaumLeNet пишет:
тут есть специалисты по хукам? еще пара вопросов висит в воздухе. чтобы не заграмождать крякерский форум подобной чепухой - в личку, если есть возможность проконсултировать.
Специалистом я себя не назову, но недавно с хуками пришлось возиться, так что можешь попробовать мне свои вопросы задать.

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

deNULL
более спасибо за наводку с хэндлами. оказывается все просто более менее ) чтобы работать с хэндлом, созданным в чужом процессе, мы копируем его с помощью ZwDuplicateObject в наш ) ну а дальше связка Query Object / SysInfo. щас реализую.

вопросы по хукам оформлю более менее, пока оформляю может сам пойму как решить )

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

NaumLeNet
Наконец-то, вспомнил. С Консультант+ была похожая песня. Там в файле есть хвостик - zip запароленный.
Тоже филимоном проверял отсутствие доступа, но мне не поверили и тоже ссылались на маппинг. Тогда я взял и просто "затер" это место нулями. Программа ничего не "заметила". Попробуй такой метод

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

попробовал. заметила )

самое главное, что я уже вроде отписался - когда повесил хуки и все сам обработал - выявились те самые переходы и чтения в "белых" пятнах (даже специально построил file map как в IDA с бегунком и раскрасками +)

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