Собственно про сабж хотел узнать такое. На 10 в последнем билде - он довольно геморойный - те не дает много чего понаделать (хорошо так карту 0 забили). Например даже создать поток на системную апи - уже нет. Не будем вдоваться в подробности - битовые карты и сам механизм ясен и прост. Есть 2 варинта работы с ним - это из эксплоита и из отдельного процесса. Про эксп - в данном случае не интересно. Я вижу норм решение просто запатчить хандлер CFG в ntdll в целевом процессе на непосредственный прыжок на функу без проверки. Но это прям слишком явно. Есть ли еще какие варианты на подумать? ПС. Пробовал историю с NtSetInformationVirtualMemory но не дает) как и SetProcessValidCallTargets (хотя это обертка для NtSetInformationVirtualMemory , но это экспортируемая функа) Спасибо.
ROP chains. Вне процесса, если у тебя уже есть права PROCESS_VM_WRITE (для WriteProcessMemory) чтоб запатчить _guard_check/dispatch_icall, можешь наделать многого другого, более прямо линейного. Тоже самое с SetProcessValidCallTargets - нэндл на процесс должен иметь довольно высокие права. То есть, наличие этих прав уже даёт сверх возможности над процессом, что оставляет обход CFG почти не нужным. Если внутри процесса, подразумевая первую стадию эксплойта: какой нибудь программный дефект с работой с памятью, типа use-after-free или что либо другое что ведёт к созданию примитива напиши-что-где-угодно (arbitrary write primitive), то ответ ROP chain: некий пойнтер на функцию меняешь на начало цепочки, прежде времено приготовля стак. (Самый практичный вариант найти stack-swap gadget который приготовленый кусок памяти вставит в esp/rsp). Ну это всё стандартно и хорошо описано в литературе. Могу скинуть ссылкы на английском. ROP цепи очень похожы на return-to-libc что лет 15-20 было описано SolarDesigner'ом. (ROP = return oriented programming, как стандартно у американцев, страшно звучащий термин к чему-то совсем не страшному).
comrade, я не очень много работал по теме сплоитов. слишком геморно. но РОПы уже не в моде ж - везде обложили) больше COP/JOP в проработке. Но тут могу быть не компетентым. На счет остального ясно. _guard_check/dispatch_icall - да я про этот патчинг.
Кто и где ROP обложил? Не видел ничего что видит его и распространено в масштабе. (RIPROP нытиков grsec не считаю.) COP/JOP это варианты того-же самого: использовать код который уже в процессе (т.е. действует даже в пресудствие ACG+CI), со спец-подготовленным вводом параметров. Если уж падчить, если память мне не изменяет, достаточно лишь обнулить пойнтер на карту битов, и guard_check/dispatch_icall будут думать что CFG выключен для процесса. Но опять же, цель CFG это затруднить эксплойтацию процесса из внутри, а не предотвращать манипуляции процесса из вне (если уже есть права на это, VM_WRITE/OPERATION). Для последнего (anti-tampering) существует технология protected processes (PP/PPL).
comrade, да суть одна и таже. просто не моя задача на данный момент - я в плане роп итд. VBOrion, он умеет в 64 бита?) Никогда им не пользовался и не любил как и олли.
Выключить DEP и CFG отвалится сам собой. Ну и да, при использовании ROP, CFG не сможет обеспечить целостность потока исполнения..
comrade, в данном случае тс - это я. Но как всегда хз что имеет ввиду инде, что там мне сложно ибо он вообще первый пост не читал походу, собственно мне все равно. По ропам и иже с ними - парни яж про них не спрашивал) Все просто по инерции начали накидывать инфу, хотя она мне не нужна - гуглить я умею, а чего нет в гугле тут никто не расскажет. По делу - я красавчик, все у меня работает, просто хотел уточнить, но comrade подтвердил мои мысли. Топик можно закрыть. Всем спаибо, даже инде)