import { assertType } from 'typescript-is';
interface User
{
firstName: string;
lastName: string;
age: number;
avatar?: string;
}
interface UsersResponse
{
totalCount: number;
users: User[];
}
/*
Тут какой-то ваш код, где получаете данные в переменную "data"
*/
assertType<UsersResponse>(data); // Если то, что в "data", не соответствует структуре UsersResponse, то будет выброшено исключениеКак писали в саппорте пионера - апворк не требует , чтобы карта была оформлена на фрилансера.
То, что VMP прекрасно девиртуализируется, это я и так знаю (раз, два, три).
И автор пока не спешит это фиксить.
А судя по тому, что автор VMP искал сторонние решения, у него пока не особо много идей в плане фиксов (по крайней мере так было год назад).
Из личных сообщений на форуме vmprotect:
Там даже TitanHide не нужен, VMP прекрасно обходится даже при помощи user mode инструментов типа ScyllaHide :)
Сейчас лучшим публичным решением можно считать продукты Oreans.
Та же Themida успешно сопротивляется как user mode отладке, так и kernel mode (на tuts4you можно найти посты, как у пользователей даже с TitanHide возникают проблемы с отладкой).
Авторы ScyllaHide добавляли обход трюка с GetForegroundWIndow, но автор протектора закрыл это в следующей же обнове.
Не секрет, что все антиотладочные и прочие трюки являются лишь "бонусом", так как основным методом значительно затруднить взлом приложения является виртуализация кода. А вот виртуальные машины у Oreans гораздо сложнее, чем у VMP.
Смею предположить, что Вы опечатались и вместо "адреса системных вызовов" имели в виду "адреса winapi функций"? Так как у системных вызовов нет "адресов", есть их коды, которые в windows меняются от версии к версии, а библиотека ntdll служит своеобразным "шлюзом" в kernel space, так как в ней "зашиты" коды этих системных вызовов.
Именно в том виде, как Вы описали, это не имеет особо никакого смысла.
Если Вы хотите, чтобы при статическом анализе не были видны вызовы winapi, то в протекторах обычно есть опция api wrapping (по крайней мере в Themida/WinLicense), которая как раз и делает так, что адреса для winapi вызовов вычисляются динамически, с кучей jmp'ов в heap и прочими трюками.
В итоге если сделать дамп такого приложения и скормить его статическому анализатору, то анализатор покажет вам ноль winapi вызовов, будто у приложения вообще нету импортов. Ну и заставить работать этот дамп, разумеется, не выйдет без фикса импортов.
Проблема лишь в том, что это все бесполезно при динамической отладке, так как реверсеру без разницы как Вы спрятали адреса.
Реверсер будет Вас "ждать" в конечной точке (в нужной системной либе).
А вот прямые системные вызовы без использования нашего "шлюза" (ntdll) - вот это уже другое дело :)
Только проблема в том, как я выше уже упоминал, что коды системных вызовов меняются от версии к версии и у нас есть 2 варианта:
1. Тащить за приложением "базу" системных вызовов для всех известных версий Windows. Так делает VMP и это достаточно легко обходится, если подменить версию билда винды (в PEB и в ресурсах ntdll). Когда VMP видит неизвестный ему билд винды, он начинает дергать winapi функции.
2. "Парсить" в рантайме ntdll, но для этого придется тащить за собой в приложении дизассемблер. Такой вариант не очень надежный.
Суть вашего сообщения понятна - кастомную защиту ломать сложнее, чем публичную.
Только тут есть одна проблема - квалификация разработчика кастомной защиты должна быть как минимум не ниже, чем квалификация разработчика публичного инструмента. В противном случае сломать кастомную защиту откажется проще, чем публичную. В этом и был смысл моего самого первого комментария к этому ответу :)