Pull to refresh

Comments 8

Мда, запилить такой софт и не запилить к нему watchdog — красавцы. А что победили — красавцы вдвойне.
Объясните мне пожалуйста, как автоматически можно создать патч, если проблема чисто логическая, например, будет скрываться в сложной логике авторизации? Т.е. я встречал проблемы, когда люди не могли придумать как исправить дыру в безопасности и всё не сломать. Как это исправить в автоматическом режиме я просто не представляю.
UFO just landed and posted this here
Настолько же мало как и какой-либок конкретики в статье.


+1
Это все работает на уровне построения дерева ветвлений бинарного кода. Грубо говоря происходит анализ байт-кода, если при определенных условиях создается возможность переполнения буфера, нужно предотвратить возникновение этих условий. Патчится там все на лету опять же на уровне бинарных кодов. Я в 2015 на дефконе это дело слушал — очень было интересно.
Патчится каким образом? При обращении к buffer[i] при i >= N программа падает или заменяет это обращение на buffer[0]? Если падает, то чем это лучше, чем сразу писать на управляемом языке?
Вы знаете как сейчас фаззинг работает?
Скармливаем кучу барахла в переменную, смотрим что упадет и при каких условиях.
Там подход противоположен, они грубо говоря запускают программу в ГДБ, и везде где данные получаются от юзера/стороннего процесса пытаются проанализировать заданы ли граничные условия для параметра. Если не заданы, пытаются эксплуатировать. ТАм инструмент может использоваться как для подготовки эксплойтов на лету, так и для патчинга на лету. Патчится это очевидно в памяти, а не на диске. Что конкретно в этой реализации сделали для предотвращения BoF я очевидно не знаю. Там конкурсантов 6 или 7 было последний раз когда я проверял. У всех свои подходы и свой проприетарный алгоритм.
Вы знаете как сейчас фаззинг работает?
Он даёт материал для размышлений исследователю. А тут как алгоритм автоматически реагирует, вообще непонятно. Вот и вы не знаете.
Sign up to leave a comment.

Articles