Добый день guru, возможно кто-то делал поиск файлов не через WinApi-FindFirst/FindNext, а через прямой доступ к диску при помощью vwin32? Поделитесь пожалуйста опытом. (Os WinNT/2000/XP)
iov Шутник. vwin32 для Win9x. Под NT доступ к диску через обычный File I/O (CreateFile,Read/Write File). Для поиска тебе потребуется написать свои анализаторы файловых систем (FAT16/32, NTFS). Если справишься — получишь прирост в скорости. Зачем тебе это вообще?
дада, конечно, а проще проанализировать FindFirst/FindNext, как написаны никак? только я не пойму для какой хрени нужна гарадить абру кадабру в обход FSD ???
я как раз и хотел узнать есть ли в системе средства для работы с нтфс и фат напрямую, на подобии того как это происходит в линейке 9х. извините, не так выразился, т.е. судя по ответам прямого доступа нет? зачем надо: заказчик хочет чтобы защита реализовывалась именно на прямом чтении с диска родных ключевых файлов и не хочет давать возможность ставить хуки SetWindowsHookEx на апишные функции работы с файлами.
lol !!! )) Можна на прямую работать с хардом , но для того чтоб получить файл ... тебе придётся так натрахаться с файловой системой что просто не в сказки ...
Лечится заказчику надо. Они никогда сами точно не знают чё хотят. Твоё дело, как разработчика, обьяснить ламеру, что даже если напишешь - рипнут код с проги, хукнут функции с проги и т.д. и т.п. Писать нортоновские утилиты ради чтения инфы с ключевых файлов - бред сивой кобылы. Усложнишь защиту в одном месте - найдут дыру в другом. Тем более, что хреноватое место для защиты выбрал твой заказчик. SetWindowsHookEx - ну твой заказчик даёт
iov в любом случае похучат твои функции, не в юзермоде(SetWindowsHookEx весьма наивно), так запросто в ядре, тут без kmd не обойтись никак. Могу дать не столь генитальный, но совет. Зачем тебе для этого дела юзать файлы ??? почему бы к примеру не хранить инфу в неиспользуемых операционной системой секторах жёсткого диска из собственного драйвера?? уже сложнее, чем файл ковырять. Для доступа к диску стандартного драйвера заглаза. Второе, к примеру, организовать общалово проги со своим драйвером не через стандартный DeviceIoControl, а, скажем, использовав обработчик #GP либо #UD, как в HASPNT. Драйвер в системе можна запрятать, для того статей MS REM'а достаточно, скрыть описатели в реестре, чтобы не похучили к примеру функции в SST, сделать копии SST для потоков своего процесса, это уже коечто, и к примеру я такого еще ни в одной защите не видел. В третьих, да имея в системе драйвер можно поперекрывать доступ ко всем важным узловым моментам и даже некоторое время водить кракера за нос, дольше думаю не получится. А сам ехек упаковать каким нить аспротектом, только по уму, с использованием его апи. Вот уже коечто. Воображение примени ))).
к сожалению, я лишь исполнитель, он же кодер, мне ставят задачу - я ее делаю. в принципе, все более-менее понятно. будем писать связку сервис/драйвер. Cпасибо CARDINAL,IceStudent за идеи.
