Windows API шпионя/угоняя методы

Проверьте свой web.config для локального экземпляра sql. не удален.

7
задан Community 23 May 2017 в 10:27
поделиться

3 ответа

Я реализовал syringe.dll (L-GPL) вместо Обходов MS (нам не нравились лицензионные требования или огромная оплата за поддержку x64), это работает фантастически хорошо, я портировал его от Win32 до Win64, мы использовали в нашем не сам коммерческое применение в течение приблизительно 2 лет теперь.

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

Быть L-GPL'd мы предоставляем источник, авторское право и т.д., и только динамично связываемся с библиотекой.

3
ответ дан 7 December 2019 в 07:53
поделиться

Сцепление стандартных функций WinAPI относительно безопасно, так как они не собираются изменяться очень в ближайшем будущем, если вообще, так как Microsoft делает лучше сохранять WinAPI назад совместимым между версиями. Стандартное сцепление WinAPI, я сказал бы, обычно стабильно и безопасно.

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

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

В gamehacking, где сцепление является общепринятой практикой, это было побеждено до некоторой степени с "sigscanning", техника, сначала разработанная LanceVorgin на несколько печально известных платах MPC. Это работает путем сканирования исполняемого изображения для статических частей функции, фактические байты инструкции, которые не изменятся, если действие функции не будет изменено. Sigscanning, очевидно, лучше, чем использование статических таблиц адресов, но он также перестанет работать в конечном счете, когда целевое приложение будет изменено достаточно.

Реализация в качестве примера sigscanning в C++ может быть найдена здесь.

2
ответ дан 7 December 2019 в 07:53
поделиться

Я использовал стандартные методы сцепления IAT в течение нескольких лет теперь, и это работает, хорошо было хорошо и стабилен и портирован к x64 без проблем. Основные проблемы, которые я имел, больше относились, как я ввожу рычаги во-первых, это взяло ярмарку, в то время как разработать, как лучше всего приостановить организованные процессы в 'правильной' точке в их запуске так, чтобы инжекция была надежной и достаточно ранней для меня. Мой инжектор использует отладку Win32 API и пока это помогло приостановить неуправляемые процессы, потребовалось немного метода проб и ошибок для получения организованных процессов, приостановленных в подходящее время.

Мое использование для IAT главным образом было для записи инструментов тестирования, у меня есть программа обнаружения мертвой блокировки, которая подробно изложена здесь: http://www.lenholgate.com/blog/2006/04/deadlock-detection-tool-updates.html, GetTickCount () управление программой, которая доступна для скачивания отсюда http://www.lenholgate.com/blog/2006/04/tickshifter-v02.html и приложение смещения во времени, которое все еще разрабатывается.

1
ответ дан 7 December 2019 в 07:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: