Page 1 of 1
std::string crash
Posted: Wed May 29, 2013 7:46 am
by kasedy
mingw (GNU Make 3.82)
VMProtect 2.12 x32
ошибка возникает в только в релиз версии при конструировании std::string с заданной длиной (например std::string("aaa", 3);).
Re: std::string crash
Posted: Tue Jun 04, 2013 9:09 am
by Admin
А какой пароль на архив?
Re: std::string crash
Posted: Tue Jun 04, 2013 9:41 am
by kasedy
прошу прощения. пароль "vmp"
библиотеки qt можно исключить из проекта
Re: std::string crash
Posted: Fri Jun 14, 2013 5:47 am
by Admin
Причина такого поведения заключается в том, что MinGW при инициализации своего рантайма патчит исполняемый код.
Было:
Code: Select all
004013F2 81FB 9C614000 CMP EBX, 0040619C
Стало:
Code: Select all
004013F2 81FB 988FCC6F CMP EBX, 6FCC8F98
В данном случае адрес 004013F2 принадлежит вашей функции crash(). В процессе виртуализации протектор используется освободившееся место для своих нужд и с большой вероятностью на этот адрес будет попадать исполнитель ВМ и результат работы такого кода будет непредсказуем (крах приложения это один из возможных вариантов).
Re: std::string crash
Posted: Mon Jun 24, 2013 11:50 am
by kasedy
Как этого можно избежать? Можно ли настроить MinGW не патчить исполняемый код или указать vmprotect не перезаписывать освободившееся место?
Re: std::string crash
Posted: Mon Jun 24, 2013 12:28 pm
by Admin
Как этого можно избежать?
Никак. VMProtect совершенно ничего не знает про то, что бинарник сам себя патчит
)
Можно ли настроить MinGW не патчить исполняемый код
Задайте этот вопрос разработчикам MinGW.
или указать vmprotect не перезаписывать освободившееся место?
Здесь гораздо больше проблем чем вы видите
) Даже если VMProtect не будет использовать это место, то все равно условие будет работать неправильно, т.к. VMProtect на этапе виртуализации будет виртуализировать CMP EBX, 0040619C, и ничего не будет знать про CMP EBX, 6FCC8F98
P.S. У "нормальных" компиляторов принято все изменяемые ячейки (если они настраиваются не операционной системой) хранить в секции данных, а не кода. В этом бы случае условие выглядело бы как CMP EBX, [var_xxx] и вообще бы никаких проблем не возникло.
P.P.S. К слову сказать у таких самоизменяющимся бинарников нельзя никак контролировать целостность секции кода, т.е. любой подсчет CRC будет всегда отличаться от правильного после того как по нему прошелся рантайм MinGW.