Проблемы защиты функций с switch/case [bcc64/clang]

Issues related to VMProtect
lazybit
Posts: 24
Joined: Thu Feb 11, 2010 12:40 pm

Re: Проблемы защиты функций с switch/case [bcc64/clang]

Post by lazybit »

Вы обычно просите тест проблемы, я вам его предоставил. Мои предыдуще тесты так же абсурдны в использовании switch/case и вообще тупые с точки зрения програмиирования, уж простите, мы тут все такие ламеры. Могу сделать тест, где будет падать и при выделении одного байта. Я как раз понимаю, как работает подгрузка страниц в стек, а ваши приведёные "шаг в правло/влево" не имеют никакого отношения к проблеме, ибо бессмысленны. Суть в том, что после защиты вашим протектором, программа перестает работать, как работала в первоначальном виде. В этом случае хотелось бы знать ограничения вашего протектора при разработке программ. Ограничения в использовании приёмов программирования, ограниченная проддержка компиляторов?

Если указатель стека находится на начале страницы памяти, то при обращении по адресу с любым меньшим адресом (хоть -1 байт) протектор будет падать, потомучто там может не быть закомиченой страницы памяти, а Windows делает подгрузку это страницы автоматически. Надеюсь, вы понимаете этот момент и ваш протектор здесь отрабатывает корректно.
Admin
Site Admin
Posts: 2566
Joined: Mon Aug 21, 2006 8:19 pm
Location: Russia, E-burg
Contact:

Re: Проблемы защиты функций с switch/case [bcc64/clang]

Post by Admin »

Хорошо. Давайте я вам объясню что у вас происходит. Для начала немного теории - операционная система не выделяет всю доступную память под стек, а выделяет только часть и на границе выделенной памяти создается страница с типом GUARD_PAGE. Размер страницы как водится равен 0x1000. Когда ваш стек наезжает на GUARD_PAGE в системе возникает исключение STATUS_GUARD_PAGE_VIOLATION, которое перехватывается системным обработчиком и он выделяется следующие 0x1000 байт и передвигает GUARD_PAGE ниже.
Теперь что происходит у вас - вы с помощью alloca "перескочили" GUARD_PAGE и оказались в памяти, доступ к которой запрещен от слова "совсем". Т.е. при доступе к этой памяти вместо STATUS_GUARD_PAGE_VIOLATION возникает уже STATUS_ACCESS_VIOLATION, на которое системный обработчик начинает вызывать обработчики исключений в самой программе и при их отсутствии прибивает процесс целиком. В вашем коде доступ к buf идет в обратном порядке, т.е. вы в итоге проходите GUARD_PAGE и в результате прибегаете к памяти, к которой доступ уже есть. Поэтому я вам навскидку предложил 2 варианта, при котором ваш пример с минимальными изменениями будет точно также крешиться даже без всяких вмпротектов и прочего. О чем это говорит? Это говорит о том, что выделять память на стеке да еще в таких количествах это очень дурная практика, которая может привести к трудно обнаруживаемым багам, связанным исключительно с механизмом работы стека.
Теперь что касается вмпротекта - для своей работы виртуальная машина использует тоже самый стек, что и защищенная функция, поэтому обращение с области памяти за GUARD_PAGE происходит сразу же после изменении указателя на вершину стека:

Code: Select all

push rbp
mov rbp, rsp
cmp ecx, 01
jnz 0000000000401267 ↓
mov rcx, rsp
add rcx, -00008000
mov rsp, rcx <--------------- изменение указателя на вершину стека
mov [0000000000416440], rcx <------------ при выполнении этой команды произойдет обращение к недоступной памяти, т.к. вершина стека находится в недоступной памяти
mov eax, 00007FFF
jmp 000000000040124B ↓
...
Ни операционная система ни вмпротект никогда не узнают какова была реальная цель этого "финта" - может быть последующее обращение к недоступной памяти это такая "фича", по которой программа понимает что что-то пошло не так, а может плохо спроектированная логика. Поэтому я вам и пишу - попробуйте вникнуть в проблему и больше так не делать независимо от того будете вы использовать в этом месте вмпротект или нет.
lazybit
Posts: 24
Joined: Thu Feb 11, 2010 12:40 pm

Re: Проблемы защиты функций с switch/case [bcc64/clang]

Post by lazybit »

Я прекрасно понимаю, что тут происходит и об этом вам уже указал в самом начале. Но как раз с операционной системой проблем нет и программа работает прекрасно, подгрузка страниц происходит без проблем, это было сделано специально, если вы не поняли. В отличии от ваших нерабочих примеров, зачем вы их привели мне не понятно. Рабочая программа не выделяет большие блоки памяти. Было уже указано, что проблема не в количестве выделяемой памяти, а в работе у границы неподгруженой страницы. Если вмпротект использует стек программы, тогда всё объясняется. Здесь несовместимость clang с вмпротектом.
А ваши заключения по работе со стеком довольно забавны, учитывая, что эти "дурные практики" выделения памяти в ростущем стеке эффективно использутся уже более 30 лет на уровне компиляторов. Правильные рассуждения: Clang генерирует не правильный код выделения памяти в стеке. Отсутсвует подкачка страниц стека (probe stack) до изменения его указателя. Так что спишем проблему на clang.
Post Reply