| Сейчас на форуме: (+7 невидимых) |
| eXeL@B —› Вопросы новичков —› Detours -- проблема с перехватом функции ReadFile |
| Посл.ответ | Сообщение |
|
|
Создано: 26 мая 2014 18:02 · Поправил: b0r3d0m · Личное сообщение · #1 Приветствую. Имеется некоторое кол-во процессов "notepad.exe". Необходимо пропатчить их таким образом, чтобы при сохранении файла текст, введённый пользователем, зашифровывался, а при загрузке -- расшифровывался. Каким именно алгоритмом будет осуществляться шифрование в данный момент особого значения не имеет, т.к. в моём случае проблема оказалась вовсе не в этом. Разумеется, первым делом у меня возникло желание использовать для этих целей . Т.е. создаём динамическую библиотеку с перехватом интересующих меня WinAPI-функций (вероятнее всего, WriteFile и ReadFile), после чего загружаем её во все текущие процессы с именем "notepad.exe" при помощи CreateRemoteThread. Перехватка функций работает, текст успешно шифруется на сохранении файла. Попытка дешифровать этот же текст путём перехвата ReadFile почему-то не работает. Взял в руки и стал наблюдать за тем, что же на самом деле используется notepad'ом для чтения файла. Да, функция ReadFile действительно вызывается для проверяемого мной файла. Добавил вызов функции MessageBoxA в код хука, поставленного на ReadFile, и обнаружил, что вызывается он не в момент нажатия на кнопку "Open" в GUI notepad'а, а при выделении документа в диалоге выбора файла. Интересно, почему бы это? Неужели notepad заранее загружает в память содержмое файла ещё до непосредственного нажатия на клавишу "Open"? Если да, то зачем? Если нет, то почему я наблюдаю подобное поведение? Более того, текст при чтении файла всё равно не подменяется на нужный мне. Специально для упрощения эксперимента пытался на ReadFile всегда возвращать в качестве прочитанных данных "str", однако даже в таком случае в GUI отображается оригинальное содержимое файла, а не "str". можно посмотреть код с хуками на вызов функций WriteFile и ReadFile. Заранее благодарю за возможные ответы. ![]() |
|
|
Создано: 26 мая 2014 18:08 · Личное сообщение · #2 |
|
|
Создано: 26 мая 2014 18:44 · Личное сообщение · #3 |
|
|
Создано: 26 мая 2014 19:49 · Личное сообщение · #4 |
|
|
Создано: 26 мая 2014 21:12 · Личное сообщение · #5 |
|
|
Создано: 26 мая 2014 21:16 · Личное сообщение · #6 |
|
|
Создано: 26 мая 2014 21:26 · Личное сообщение · #7 |
|
|
Создано: 26 мая 2014 21:29 · Личное сообщение · #8 Dr0p пишет: Конечная цель какая Конечная цель в шифровке и дешифровке как раз и заключается. Dr0p пишет: можно безпалевно(без патчей) всё мониторить, тот же например диалог Вы про функции наподобие FindWindow? В любом случае, мне же не сам диалог мониторить надо, а события сохранения и загрузки текстовых файлов. ![]() |
|
|
Создано: 26 мая 2014 21:36 · Личное сообщение · #9 |
|
|
Создано: 26 мая 2014 21:44 · Личное сообщение · #10 Dr0p пишет: Сомневаюсь что вам нужен именно блокнот, им никто не пользуется и даже не знает как запустить Да нет, почему же -- у нас полно подобных людей, например. Dr0p пишет: Походу на примере блокнота откатывается технология, которая будет юзаться на другом софте Я в целом хочу поднабраться опыта, а не задалбывать вопросами о конечном продукте в стиле "мужики, сделайте за меня, я не хочу ни о чём думать самостоятельно". Добавлено спустя 4 часа 28 минут Оказывается, Process Monitor почему-то просто не перехватывает вызов функции MapViewOfFile. Попробовал проделать то же самое с winapioverride -- да, вызов MapViewOfFile действительно имеется. | Сообщение посчитали полезным: Dr0p |
| eXeL@B —› Вопросы новичков —› Detours -- проблема с перехватом функции ReadFile |









Для печати